期待のネット新技術

DRAMサポートを追加した「OpenCAPI 3.1」、メモリインターフェース統合を考慮も、Gen-Z競合にはなり得ず?

【InfiniBandの現在】

 「InfiniBandの現在」では、規格としての歴史と現状、今後の動向をまとめて紹介している。大半の読者にとっては「InfiniBandって何?」というところだろうが、僚誌クラウドWatchをご覧になっておられる読者の中には「何で今さら」という方も居られるかもしれない。

 そう、InfiniBandという規格は、1999年に作業が始まり、2000年に最初の規格策定が行われたという「えらく古い」規格なのである。

「InfiniBandの現在」記事一覧

アクセラレーターやネットワーク、SCMを直接ぶら下げる「OpenCAPI 3.0」

 OpenCAPI 3.0に関して言えば、以下の図のようにアクセラレーターやネットワークあるいはSCM(Storage Class Memory)を、CAPIのポートにまとめてぶら下げるという構成だった。この点は、競合する「Gen-Z」や「CCIX」、「CXL」の各規格と同じだ。

OpenCAPI 4.0は現在はTransaction LayerのDraft 1.2のみが一般公開されている状態で、標準化を終えるまではまだ時間が掛かりそうだ。出典は"OpenCAPI and its Roadmap"(PDF)

 この場合、SCMがどう見えるかは、ドライバーの書かれ方次第だ。キャッシュコヒーレンシが保たれるということは、つまりランダムアクセスが可能ということになる。ただ、SCMのほとんどはNANDフラッシュベースで、ほぼ100%がブロックアクセスとなる。このあたりは、NORフラッシュや、それこそIntelの「Optane Memory」、あるいはMRAM(Magnetoresistive Random Access Memory:磁気抵抗メモリ)などでは話が変わってくるが、それはおいておこう。

 ブロックアクセスしかサポートしないSCMに対してランダムアクセスを掛ければ、猛烈な待ち時間に発生する。このため、通常はSCMの側に小規模なバッファメモリを置き、Interconnect(この場合ならばOpenCAPI)はこれに対してアクセスを行う。SCMの側は、そのバッファへのアクセスが発生すると、これに応じてSCMに対するブロックアクセスを行い、その結果をバッファメモリに返す、というかたちになる。

 ただ、この方式だと、ホストからSCMへの書き込みに関して言えば、まずバッファに対してOpenCAPI経由でデータが書き込まれ、終わればホストに制御が戻るので、あとはバッファからSCMへゆっくり書き戻せばいい。

 ところがSCMからホストへの読み出しのケースでは、前触れなくSCMに対してリードのリクエストが届くわけで、そこからSCMへアクセスし、結果を読み出してバッファへ書き戻すまでには、かなりの時間が掛かってしまう。

 それもあってSCMはメモリとして扱うというよりも、高速なファイルシステムとして扱う方が合理的だ。つまり、基本はストレージ扱いとなるわけで、上の図で言えば4に近い。

 ただ、図に3が存在するのは、冒頭にも少し書いたように、ランダムアクセスが可能な不揮発性メモリも存在するからだ。つまり、コストパフォーマンスや絶対容量はともかくとして、技術的にはこれをサポートできる余地を残しておこう、という話だと言える。

DRAMサポートを追加した「OpenCAPI 3.1」、72bitパラレルバスを8bitへ変換、多数のメモリチャネルをホストへ接続可能に

 さて、ここまではOpenCAPI 3.0の話だが、2017年1月にリリースされた「OpenCAPI 3.1」で追加された主要な項目は、前回も掲載した右のスライドにもあるように、DRAMのサポートだ。

 ここにある「Based on an Open Memory Interface(OMI)」は、IBMがPOWER9と併せて発表した技術だ。基本的なアイディアは以下左の図の通り、低レイテンシーと高キャパシティの双方を1つの技術で実現しようというものだ。具体的には右の図のように、要はデータだけで64bit、エラー訂正まで含めて72bitのパラレルバスを8bitへと変換することで、より多数のメモリチャネルをホストに接続可能とするものだ。

 8bitと言っても、実際には信号がディファレンシャルになるため16本となるが、それでも72bit=72本となる従来型のDIMMに比べて、同じピン数ならば4.5倍のメモリチャネルを接続できることになる。

基本は間にバッファを挟むかたちだが、いわゆるバッファメモリというより、かつてのFB-DIMMに限りなく近い。出典はHotChips 31における"IBM's Next Generation POWER Processor"(PDF)
複数のDIMMをディジーチェーン式に1本のチャネルへ接続できたFB-DIMMとの最大の違いは、リピーターの構造とはなっていない点だ
ロゴからも分かるように、このバッファチップはMicrochip(がかつて買収したMicrosemiの部隊)が開発を手掛けている。オープンという割に提供ベンダーが今のところMicrochipしかないのは、POWER9専用という限られたマーケットによるものだろう

 右上の図にもある通り、OMIのバッファを介することによるレイテンシーの増加は5~10ns程度(LRDIMMと比較した場合は5ns未満)と、極めてオーバーヘッドの小さい構成となっている。

 右の図がバッファチップの内部構造で、DeskewやFrame Formattingなど若干の機能は入っているものの、基本的には72bitパラレルバスと8bitパラレルバスを変換するだけの比較的シンプルな機能だ。

こういう独自DIMMが許されるのも、POWER9のみがターゲットだから、という面はもちろんある

 実際のモジュールは右のようなもので、その右側が今回のOMIに準拠したOMI DIMMだ。この構成だとSDRAMチップは9個だが、以下左のように、裏面も使ってトータル18個の構成も仕様上はサポートされている。

 ちなみにこのスライドだけだと、独自のDIMMを用いるのが必須のように見えるが、コントローラー開発元のMicrochipは、以下右のように、通常タイプのRegistered DIMMと組み合わせる方式も提案している。

現在JEDECに標準化提案を出しているそうだが、果たして採択されるか……
このケースでは、「SMC 1000」コントローラーはマザーボード側に搭載される格好になる。出典はMicrochipのSMC 1000 8x25Gのアプリケーションノート

 話を戻すと、このOMIの仕様が取り込まれたことで、OpenCAPI 3.1は単にSCMだけでなく、DRAMもサポートできるようになったわけだ。もっとも現時点では、これは半ば詭弁と言える部分もある。

 というのは、OMIに関して言えばPHYが全く異なっているからだ。例えば、アクセラレーターやネットワークコントローラーから、OMIの先のDRAMへ直接アクセスできるわけではない。一度OpenCAPI 3.0のPHYを経由してホストのメモリコントローラーにアクセスし、そこからOMIの先にあるDRAMへとアクセスするかたちになる。要するに、ホストのメモリコントローラーがルーティングを行っているかたちであり、これを「OpenCAPIでDRAMもサポート」と称するのは、やや苦しい部分があるだろう。

OpenCAPI 4.0で、メモリとI/Oのインターフェース統合を見据えるが……

 ただ、言ってみれば、これは現実的な対応策であって、OpenCAPIそのものにDRAMアクセスの機能を内包させるには相応の時間が掛かり、登場時期はその分遅くなる。そこで暫定的にOpenCAPI 3.1ではDRAMサポートをオプション扱いとして追加し、時間を稼いでいる間にOpenCAPI 4.0以降できちんとインテグレーションしよう、という方針だろうと思われる。

 実際、PHYの電気的特性そのもので言えば、OpenCAPI 3.0も3.1も25Gbpsのx8構成になっており、ある意味互換性は保たれている。問題は、アクセラレーターやネットワークコントローラーを繋ぐポートと、OMIを繋ぐポートが現在は別々になっている(というか、せざるを得ない)ことだろう。

 将来的にI/Oもメモリも完全にOpenCAPIで統一できるような構造になれば、本当の意味で「OpenCAPIでDRAMも扱える」と言えるようになるだろう。OpenCAPI 3.0でHome Agent Memory on OpenCAPI Endpointの機能が追加されているのは、こうしたメモリインターフェースとI/Oインターフェースの統合を見据えたもの、という気がする。

 だいぶ話が逸れたが、現状、OpenCAPIがGen-Zの有力な競合相手となっているのは、単にアクセラレーターをキャッシュコヒーレンシを保って繋げられることだけではない。メモリインターフェースの統合までを考慮している上、実際に製品が出てきていることは、むしろGen-Zを一歩リードしている感もある。

 その一方で、OpenCAPI陣営にとって厳しいのは、オープンと言いつつ、対応するホストアーキテクチャーがPOWERに限られることだろう。前回も書いたように、当初はOpenCAPIにAMDやDell EMC、HPEが参画していた。この状況が続き、仮にAMDがOpenCAPI対応のx86サーバー向けプロセッサーをリリースし、これを採用したサーバー製品をDell EMCやHPEが市場投入したりするなら、また話は変わっているだろう。

 ところが現状、プロセッサーを提供しているIBM以外のメンバー企業をみても、Strategicとしては、TPUを自社製造するGoogleと、GPU以外にARMベースのSoCを組み込み分野や自動車向けに提供しているNVIDIAのみだ。Contributorとしても、ARMベースのサーバー向けSoCを提供するCavium(現Marvell)、モバイル向けSoCと、一部サーバー向けSoCを提供するSamsungくらいのものだ。

 正直、今後IBM以外のメーカーが、OpenCAPIに対応したサーバー向けプロセッサーやSoCを提供する公算は限りなく低い。仮にOpenCAPI陣営がARMあたりを引き込むことができれば話は変わるだろうが、CCIXとGen-Zを自社のInterconnectの中核に置くARMは、OpenCAPIには興味を示しておらず、この状況はおそらく今後も変わらないだろう。OpenCAPIは機能的にはGen-Zにかなり近いと言いつつも、これが理由で実際にはGen-Zを脅かすまでには至らないと考えられる。

「InfiniBandの現在」記事一覧

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/