HBAとMPIとの組み合わせで、低レイテンシーを安価に実現した「RDMA」

InfiniBandに当初から実装され、MPIの低レイテンシーを支える「RDMA」

　前回は「MPI（Message Passing Interface）」について紹介したが、これを支える技術が、InfiniBandに当初から実装されていた「RDMA（Remote DMA）」である。

　そもそもMPIにしたところで、単にInfiniBandを従来と同じ方法で利用したときには、帯域はともかくレイテンシーの観点から見ると、ほかのInterconnectとは全く変わらない。InfiniBandを使ったMPIのレイテンシーが非常に少ないのは、InfiniBandを利用した場合のレイテンシーが極端に低いためである。

RDMAを使わないと、高CPU負荷とバッファーのメモリ内コピー頻度が問題に

　以下の図は、RDMAを使わずにInitiator（送信側）からTarget（受信側）にデータを送ろうという場合の簡単な模式図だ。

　RDMAを使わない場合は、まずアプリケーション内のバッファーにデータを格納し、それをミドルウェア（例えばイーサーネットならTCP/IPのスタック）に渡す。ミドルウェアはこの渡されたデータに対してヘッダーやフッターを付加したり、CRCを計算して追加したりと、さまざまな作業を自身のバッファー内で行ってから、それをドライバーに渡す。

　ドライバーは、渡されたデータをOSの内部キューに格納し、次いでI/Oのリクエストを出す。これを受けてOSは、自身の内部キューの内容を「HBA（Host Base Adapter）」のバッファーにコピーし、ハードウェア的にI/Oリクエストを発行する（HBAのどこかのレジスタに書き込みを行う、など）。

　この結果として、Initiator側のHBAのバッファーにある内容が、Target側のバッファーにコピーされることになる。ここからは逆の手順で、最終的にアプリケーションのバッファーへデータがコピーされ、一連の転送手順が完了するわけだ。これは典型的なI/Oのやり方で、柔軟性とか相互接続性、移植性などに優れる手法ではあるのだが、以下のような問題もある。

• レイヤーを重ねるごとにバッファーの内容のコピーが発生する。同一マシン内のメモリ内コピーとは言え、積み重なると所要時間は馬鹿にならないし、CPUの負荷も決して小さくはない
• CPU負荷は、転送速度が上がるほど増える。特に当時のInfiniBandは2Gbpsをターゲット（信号速度は2.5GT/secだが、8B10Bエンコードの利用により2Gbps=256MB/sec）にしていた。バッファーのコピーやCRCの計算などは、この速度に間に合うよう行わねばならない

　特に後者は、当時のCPUにとって決して低い負荷とは言えなかった。2017年とやや前だが、ギガビットにおけるジャンボフレームに絡んだ話をしている。このとき、以下のグラフとともに、UltraSPARC IIiを利用したSunのワークステーションで、MTUを1.5Kにすると400Mbps程度で頭打ちになり、しかもCPU利用率が100％に達しているのに対し、MTUを9Kにすると600Mbpsを超える一方、CPU利用率は55％に落ちるという話を紹介しているが、根っこはこれと同じだ。

出典はEthernet Allianceのホワイトペーパー"Ethernet Jumbo Frames"（PDF）

高CPU負荷と同一マシン内のメモリ内コピーの問題を解消する「RDMA」

　これらの問題に対する解決法として提案されたのが、RDMAとなるわけだ。RDMAという技術そのものは、10GbEに絡んで、以前、簡単に紹介したが、要するにアプリケーションが直接HBAとやり取りすることで、余分なオーバーヘッドを削減しようという仕組みである。

　このあたりは、Hostの種類（単にx86かそれ以外か、だけではなく、WindowsなのかLinuxなのかそれ以外なのかによっても、だいぶ差がある）で若干インプリメントに違いがあるが、RDMAで最もオーバーヘッドが少ないパターンは、以下の図の赤い実線のルートである。

　一番最初、アプリケーションが立ち上がってInitiatorとTargetがお互いを認識し、通信パスを確立するという辺りまでは、黒の破線のルート、つまりRDMAが使われない先の図と変わらない。ただ、一度パスが確立したら、その後は赤い実線ないし赤い破線のルートでの通信が可能になる。技術的な難易度が高いのは赤い実線の方だ。

　こちらは、あらかじめ（つまり黒の破線で初期設定を行っている間に）、メモリI/O空間（HBAから直接アクセスできる物理メモリ領域）を、アプリケーション側で自分の仮想メモリ空間にマッピングしておく。こうすると、アプリケーションがそのマッピングした領域にアクセスしたとき、それをHBAから直接参照可能になる。これを利用して、以下のように途中の処理を全部飛ばして、いきなりデータが送れるようになる。

• 1.アプリケーションがマッピングしたメモリ領域にデータを書き込む
• 2.HBAがDMAを利用し、そのデータを自分のローカルの（つまりHBA上の）メモリにコピー
• 3.HBAはそのデータを送り出す

　この場合、これまでミドルウェアで処理していた、ヘッダー／フッターの付加や、CRCの計算といった内容を誰がするのか？　ということになるが、それは全てHBA側でオフロードすることになる。このため、アプリケーションから見れば、本当にバッファーにデータを書き込むだけで、後は何もしなくても勝手にデータが送られていくイメージになる。

　実際、HBA上の処理プロセッサは、ラインレート（InfiniBand 1.0で言えば250MB/sec）でこうした処理が行えるように設計されているから、HBAがボトルネックになることもない。例えば 1.で「アプリケーションが書き込みを行って転送をさせたい」というリクエストを出したいときに同期をどうするかというと、マッピングしたメモリ領域を利用して一種のセマフォを構築して、HBAが常にそこを監視しているといった手法を実装することで、CPU負荷を減らすことが可能だ。

　ちなみに先の1.～3.は、図で言えばInitiator側の処理になるので、Target側は以下のようになる。

• 4.HBAにデータが到着
• 5.HBAはそのデータをアプリケーションがマッピングしている領域にDMAを利用してコピー
• 6.HBAからアプリケーションに転送完了を通知

　この際にCRC32をチェックし、データの正当性の確認（と、間違っていた場合の再送リクエスト）や、ヘッダー／フッターの除去などは、すべてHBA上の処理プロセッサが行ってくれる。

　このやり方が一番高速なのだが、Hostの環境によってはメモリI/O空間をアプリケーションの仮想アドレスにマッピングできない、なんてケースもある。そうした場合には、赤い破線のように（ミドルウェアをバイパスして）、いったんドライバーに渡すことになる。

　さすがにドライバーのレベルでメモリI/O空間へのマッピングができないことはない（できないとしたら、それはそもそもメモリI/Oという概念がないことになるが、大昔はともかく現行でそんなシステムは聞いたことがない）ので、ここからは同じルートで処理が行えることになる。

　こちらは処理がワンステップ余分に挟まる分、ややレイテンシーは増えることにはなるが、それでもミドルウェアで行っていた分の処理をHBA側にオフロードできるし、メモリコピーの頻度もずっと減るので、RDMAを用いないケースよりも高速になる。

RDMAを実装したHBAとMPIとの組み合わせで、低レイテンシを安価に実現

　InfiniBandは、Release 1.0の時点でこのRDMAの仕様を策定しており、これを実装したHBAをMPIと組み合わせることで、ほかのInterconnectに比べ、ずっと高速というか低レイテンシーでのMPIの動作が可能になった。このことは、InfiniBandがHPCのマーケットで生き延びることができた大きな要因の1つとなった。

　ちなみに別の要因は、元々サーバー市場で広く利用されることを前提に、多くのメーカーがここに参入していた結果として、HBAやスイッチといったコンポーネントが、競合製品よりずっと安かったことにある。速くて安く、しかもソフトウェアサポートがそれなりにある、という状況であれば、ほかのInterconnectを駆逐していくのは、火を見るより明らかであった。

　もっとも、2000年前後にこれをHBAに実装するのは、決して容易ではなかった。Intelが最終的にHBAの開発を放棄したのは、RDMAサポートにまつわる処理プロセッサ周りの実装が追い付かなかった（Intelはそもそもx86の会社だったので、こういう処理はHost側CPUで行うべしという思想だ。しかしながらHBAにx86を突っ込むのは当然無理で、そのあたりに困難があったと想像される）ためで、逆にこれを乗り越えたMellanoxやQLogicなどのベンダーが、HPCマーケットにおけるシェアを握ることができた、ということなのだろう。