CCIX vs CXL(2) CCIXとは何なのか？

CCIX

そのような背景があって、2016年5月にCCIX Consortiumが設立された形だ。この設立直後に行われたXilinxの記者説明会でCCIXの概略が紹介されているが、まだこの段階ではあまり細かい話は出ていない。ただ、2018年のXDFのセッションでは色々細かな話が出てきて、概略はこれで理解できるかと思うが、もっと細かい資料がその後色々出てきたので、もう少し細かく紹介したい。

まずCCIXの実装であるが、PCI Expressの上にCache Coherency Protocolが載る形だ(Photo02)。ただPCIeそのままだと、Processor Memory Direct AccessもCache Coherencyもサポートされない(いやアプリケーション層でこれをサポートすれば可能だが、オーバーヘッドが大きすぎる)。そこでCCIXではPCIeのPHY層とDataLink層はそのまま流用(厳密には若干変更はある)し、その上にCCIXのProtocol Stackを載せる形になっている(Photo02)。

Photo02:その意味では、PCIeの上に載る、というよりはPCIeの下位層を流用している、という方が正確かもしれない

Cache CoherencyはProtocol Layerでサポートされる(Photo03)が、ここでの役割を今回はちゃんと書くと

Request Agent:システム内の異なるアドレスに対してRead/WriteのTransactionを行うが、この際にそのAccessしたアドレスをCache可能である。Request Agentは1つのCCIXシステム内に複数動作し、それぞれのAgentは処理機能(メモリやI/Oアクセスの機能)を1つ以上保持することが出来る。基本的にはRequest Agentがキャッシュの一貫性を保持するため、プログラマからは見えない。
Home Agent:CCIXで利用可能なメモリについて、CoherencyおよびMemory Accessの管理を行う。Cache Line内の状態を変更する必要がある場合、Home Agentから該当するRequest AgentにSnoop Transcationを送信することで、Coherencyを管理する。
Slave Agent:CCIXではAcceleratorや周辺機器などに搭載されているメモリを、システム側のメモリの一部として扱う事が出来る。この場合、Home Agentは自分自身のメモリ(つまりHost側のメモリ)しか管理しないため、Acceleratorなどに搭載されたローカルメモリを管理するのがSlave Agentである。Slave AgentはHome Agentとだけ、通信を行う。
Error Agent:Protocol Error Messageのハンドリングを行う。このError MessageはすべてのCCIXコンポーネントから送られる可能性がある。

といった具合である。

Photo03:このスライドも以前掲載したものである

ちなみにそのCCIX(というかProtocol Layer)でサポートされるCache Coherencyの状態がこちら(Photo04)。元々の発想が、ArmなどのSoCを利用しているベンダーの意向が強い事もあってか、AMBA CHIにかなり近い。

Photo04:Unique Dirty Partialがちょっと面白い

Cache Coherencyはそんな訳でCCIXのProtocol Layerで実装されるが、ではProcessor Memory Direct Accessは？というと、やはりPCI ExpressのATSを利用して実装される(Photo05)。このあたりはExoskeletonにちょっと似ている。ただExoskeletonは、コードの書き方にかなり制約があった(というか、OpenMPを使って何とかしようとしていたので、OpenMPを利用する必要があった)のに対し、CCIXではATCさえきちんと見ていれば、それ以上はあまり考えずにコードを書けるので、大分楽になったと言える。

Photo05:Host側のMMUのうち、各Acceleratorがアクセスする範囲はAccelerator側(のPCIe)のATC(Address Translation Cache)にコピーされる形

ところでこれ(Photo06)はXDFでも出てきたスライドであるが、問題はこれをどうルーティングするかである。

Photo06:まぁArmなどはSoC同士の接続に使うといったケースも想定しているため、単純なAcceleratorの接続だけでは不十分なのは明らかで、逆にこの辺はアプリケーション依存にしてしまっても問題ないと判断されたのかもしれない

これについてはArm TechConの際にCCIXのブースで聞いてきた。結論から言えば「CCIXにルーティングメカニズムは含まれない」のだそうである。だから、例えばCCIXのSwitchとか、CCIXを利用してのAcceleratorの相互接続などに関しては、SwitchなりAcceleratorなりがProtocol Layerのさらに上位層で自分で管理する、という形になるそうだ。

ついでにソフトウェアに関してもちょっと補足しておく。CCIXはDriverless Model(つまりAcceleratorのMemoryとProcessor Memoryが、アプリケーションから見ると等価にアクセスできるので、特にDriverが必要ない)を目指しているという話はこちらに書いた通りだが、OSカーネルに若干の追加が必要(Photo07)である。

Photo07:以前の記事のPhoto12のキャプションでUEFIには未対応の模様と書いたが、これは正確ではなかった

このCCIX Extensionが最小限必要であり、これが利用できるとCCIXでNUMAが可能になる(Photo08)。

Photo08:もちろんNUMAでなくUMAにすることも可能

ただAcceleratorを使う場合には、単にMemoryのRead/Writeだけでは不十分(少なくとも同期を取るメカニズムが無いと、ProcessorがPollingでAcceleratorの状態を常に確認する必要があり、あまり賢明ではない)であり、そうした場合にはVF(Virtual Function)を利用する形になるとの話であった(Photo09)。