さて、そんなCCIXのインプリメントがPhoto07となる。
-
Photo07:ちなみにホワイトペーパーによれば、CCIX 1.0のPHYでは最大25GT/secまでの転送がサポートされている。そのためPHYを16GT/25GTのデュアルモードとすればより性能があがる、と説明している
CCIX 1.0ではPCIeのPHYとデータリンクを共有する実装がメインだが、本来CCIXはPHYに関してかなり自由度があり、複数のPHYをサポートできる。独自なのはTransaction Layer以上で、ここは独自となるが、例えばフローコントロールがCredit Baseというあたりは、基本的なアイデアはPCIeに近いのではないかと思う。またPort Aggregationがさらに上のProtocol Layerに実装されているというのも面白い(PCIeだとこれはLink Layerでの実装である)。
Protocol Layerの実装というか、概念図をPhoto08に示す。CCIX Portに対して複数のRequest Agent/Home Agent/Slave Agentと、1つだけError Agentが存在し、これらが共同してキャッシュコヒーレンシを維持する仕組みとなっている
-
Photo08:このスライドはざっくりしすぎているが、CCIXのホワイトペーパー(「An Introduction to CCIX」にはもう少し細かく説明がある。Request Agentはアクセラレータに対してのI/Fを、Home Agentはキャッシュコヒーレンシの管理を、Slave Agentはメモリに対するI/Fをそれぞれ担う形である
Photo09がCCIXを利用してのトポロジー構成例である。NVLINKなどと同じくスイッチの存在も許すので、直接接続以外にもスイッチ経由での接続も可能であり、さまざまなトポロジー接続が可能とする。
-
Photo09:筆者のTwitterでも呟いたのだが、CCIXを使うとHyperCubeとか簡単にできそうな気がする
ただこうした複雑な構成の場合、そのトポロジー管理を誰が行うのかがホワイトペーパーを読んでも良く分からなかった。PCIeにおけるRoot Complexに相当するものがCCIXでは存在しない(Home Agentという訳でもなさそうだ)からで、このあたりはちょっとCCIX Consortiumに確認したいと思う。
CCIXがもう1つ面白いのは、ソフトウェア側の話である。アクセラレータの接続であれば、ドライバが介在するのは普通だが、メモリ接続となると普通はドライバは介在しない。これもあってCCIXはドライバレスモデルを目指しているとする(Photo10)。
ちなみに管理機構は、当面はPCIeのものをそのまま利用する模様だ(Photo11)。
-
Photo11:将来的にはPCIeを使わない形でCCIXが実装される可能性もありそうなので、仕組みとしてはPCIeのエラーレポーティングやマネジメントを利用しつつ、実装は異なる形になっていくのかもしれない
またソフトウェア側にて、今後提供予定の機能はPhoto12に示されている。
さて、CCIX ConsortiumはすでにCCIXのアプリケーション適用例をいくつか示している。最初の物がKVM Acceleration(Photo13)で、アクセラレータへのI/Oを削減できる(キャッシュコヒーレンシだから、書いたらそのままアクセラレータに反映される)ほか、データ構造をそのまま受け渡しできることで、CPU負荷を75%減らし、2倍のスループットを実現できたとしている。またすでに25G/56Gでのデモも行われたそうだ(Photo14)。
最後にXilinxのCCIX対応ラインアップについても説明があったので紹介しておきたい。現行のVirtex Ultrascale+の場合、4つのPCIe Gen3×16をPCIe Gen4×8構成として、ここにCCIXを通す形となるそうだ。またキャッシュはとりあえずソフトIP(つまりファブリックを利用しての実装)となっているとの事である。
ざっくりとCCIX周りをご紹介したが、10月16日からスタートするArm TechCon 2018でもCCIX Consortiumがブースを設けるそうなので、ここでもう少し色々聞いてくる予定である。