RDMA

・SSDのリモートDMAを実現する「NVMe Over Fabrics」


当時僕たちが夢見たRDMA。あとでちょっと書く。

追記。

人はなぜかblock deviceをネットワーク越しにアクセスしたくなる。オレも15年くらい前に自前のnetwork block deviceを実装したことがある。そこでRDMAという概念を知り、ああこれは素晴らしいね！と思うのだが…。

この辺りを斜め読み。

・NVM Express Over Fabrics - openfabrics
・NVMe over Fabrics - SNIA
・NVMe Over Fabrics Flash Memory Summit
・NVM Express over Fabrics - chelsio
・NVMe over 40GbE iWARP RDMA

生きていたのか！iWarp！net effectの恨み、まだオレは忘れていないぞIntelめ。ごめん書かずにはいられなかった。

うーん、結局iSCSIの代替かーという印象。というか今の会社に入ってからこのアーキひたすら考えてたわーそんなオレすげーではなく、いやこれ単にRDMA言いたいだけなんじゃないの、と。

突き詰めると、DASとの差別化が難しくなる。単一ホスト下でPCIe（でもなんでも良いけど）をファブリックで伸ばして単純にストレージデバイスとして見せた方がどう考えても楽。ハードの割り込みも直で取れるし。特に細工しなくてもBIOS（UEFI）がデバイスを見つけてくれる。

資料の中には割り込みもサポート、と書いてあるのもあるけれど、ネットワークで割り込みを中継したら低レイテンシとは口が裂けても言えないだろう。ネットワークは非同期なのが良いところ（しかも無責任にね）で、そこまで同期的に動くならそれはもうバスだ。

いやPCIe extendedな距離ではなくて、もっと遠距離に飛ばしたいんだというのであれば理解できる。某N社のexpetherという手もあるけれどね。でもそれだったらOver EtherでOK。Over Fabricと書く以上、遠距離ではないだろう。

ストレージを集中管理したいというニーズはある。ただRDMAというものが恐ろしく複数ホストからのシェアリングに向いていない。当然だがそのセクタないしアドレスを特定のホストが占有する。占有する為に、予めMPI同様にそのアドレスをregisterする必要がある。ROなら問題ないけど、だったらfile systemレベルを選択したくなるし、それはもうNASの世界だ。

うーん、どうやってもoffloadにしかならない。それもかなり古いアーキの。

だから個人的には抽象レベルを一段引き上げるべきだと思う。逆にまずRDMAから離れるべき。remoteのNVMeホストは配下デバイスを全て仮想アドレス（+α）で持ち、それに対してのDMAを実行する。つまりIOMMUのように仮想アドレスと実アドレスを変換するような機能をネットワーク越しに提供すればいい。そのアドレス群に対してクライアントはmulti queueからScatter/Gatherすれば今っぽいと思うんだけどな。あ、今思いついたこれをRemote SGと呼ぼう。

あ、でもそれなんてNetwork MMU？(IBMがそんなものを作っていた気が)

奥さん、もう12月ですってよ

・Advent Calendar 2015

去年はすごい辛かったので今年は書かないぞー！ジョジョ！

というか今年はあんまりネタが無いよね。台北に引きこもっていたから。SC15に行きたかったけど、予算も時間も無いので安藤壽茂さんのレポートを読んで行った気になるプレイ中。

・Hisa Ando
・ 安藤壽茂

memo

・MS、ブロックチェーンサービス「Ethereum Blockchain as a Service」を発表

・スラド

仕事柄いろいろこの方面の話を聞いており、ちょっと気になる感じ。そういえばオレも数年前に分散型バックエンドDBの原型みたいなの作ったなー。あまりにLayerが低すぎて失敗したけど。あそこは逆に上に行くべきだったのだけど、上に行くと当時は興味の方向性が合わなかった。blockchain 2.0とかも始まって来ているので、この分野がもっと伸びると楽しいな。

winドライバ証明書のはなし

・Windows10では個人でのドライバ開発が不可能に？

・準備OK？　EVコードサイニング証明書の現状とその実際

スラドより。ZYNQあたりのFPGAで遊んでいると意外と困るやも知れぬ。DDKが無料配布になってからMSもオープン化の波に乗り始めたなーという感想を持っていたものの、OS自体のセキュリティを考えると致し方ないのかな。たぶんデバッグモードではインストールできるとは思うけれど、常用するわけにはいかないだろう。

うーん、jungoが儲かりますなあ。Xilinxが出しているサンプルアプリケーションのドライバがjungo製でソースが公開されていない為、VerilogソースからLinuxドライバを書くはめになって、Verilogのバグをデバドラで吸収してたりすると地獄を見るパターンを思い出した。

Linux IPC

久しぶりにLinuxのプロセス間通信を見直す機会が。ガシガシその辺りを書いていたのも、もう15年くらい前なのでさぞかし状況は一変しているのだろうと思いきやそうでもなかった。まぁ普段フレームワーク上で作業している分には縁遠い話ではあるけど、やっぱりDistributedな世界だと基本だよねーと適当に検索していたら比較的新しい資料を見つけた。参考になります。

・An introduction to Linux IPC

AMD FX-9590

最近はx86系のMBを作る仕事もあまりなく、あっても利益がでるような構造にもなっていないので、お断りすることが多い。それかSuperMicoroやAxiomtek辺りの製品リストを見せてこれらのどれかに合わせるのを薦めている。

というわけで、最近のCPU事情にすっかり疎くなった。ハードが雲の向こうに行ってしまったのもあるし、会社の予算もすっからかん。CPUリストとにらめっこしたのは、2年半くらい前に自前で組んだのが最後だったように思う。

そんな中、AMDのFX-9590を評価する機会を得た。わーい！4.7Ghzの8コア220Wだぜ～！どう考えても空冷じゃ無理！こんなに熱いのだからきっと爆速に違いない！

結果。

遅い。死ぬほど遅い。何か間違えているのではなかろうかと思うくらい遅い。あまりに信じられない数値に思わずぐぐる。

・Single Thread Performance

スコア1723、Rank253。うっそ～ん。8コアなのでトータルのパフォーマンス自体は悪くないのだが、如何せんコア単体が遅すぎる。

2年半前、オレが自前で組んだ時に使ったのがi5-3570K、3.4Ghzでスコア2030、88位。ちなみに1位のi7-4790Kが2530。確かにCore2以降はIntelの独壇場だとは思っていたが、まさかここまでとは。

ついでに今日現在の値段も調べてみた。

i7-4790K、最安\41800。

i5-3570K、もう売ってないのでオクで\18000前後。

FX-9590、最安\29345。

性能差ほど安くも無く。ただ8コアなので汎用機的に使うのならば良いのかも知れぬ。ひたすらエンコするにはお買い得とも言えるが、ゲームのようにピーキーなのには向いていない。

Athlon64までずっとAMDだったので、次世代のZENに期待。x86_64アーキをIntelに飲ませた頃のAMDをもう一度。

ExpressFabric PCIe Switch Chips

・ExpressFabric PCIe Switch Chips

PLXじゃなくて今はもうAvago。PEX85XX系86系87系と順調に進化を続けて、ついに97系。いや～この石すげ～ワ～。HPCの内蔵やマルチキャストDMA、ネットワークを意識したDMAディスクリプタにBDFのマスカレード等々。

ラック内でバックプレーンをコネクタで接続している分には大した問題にはならないのだが、最終的に外にケーブルを出してx8のパラレルで繋ぐとなると…。

#しかし完全に先越された。

くっ…くやしくなんかないんだからねっ！