# GPUDirect RDMA ## 定義 GPUDirect RDMA(GDR)は、CUDA 5.0で導入されたNVIDIA GPUDirect技術の拡張機能で、InfiniBand HCAのようなサードパーティPCIeデバイスがホストメモリを経由せずGPUデバイスメモリを直接読み書きできるようにする。NVIDIAはMellanoxと提携し、OFEDスタックを拡張してInfiniBandクラスタ向けにこの機能を提供した。GPUDirectはCUDA 4.0でホストメモリ領域のGPU・ネットワークアダプタ間共同登録を可能にし(追加コピーの回避)、CUDA 4.1でGPU間のPeer-to-Peer(P2P)コピーを実現したのち、CUDA 5.0のGDRでネットワークアダプタとGPUメモリの直接データパスに到達した([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 ## GDR導入初期(2013年時点)の性能特性 - GDRはinternode GPU-to-GPU通信のレイテンシを、ホスト経由ステージング(GPU→ホスト→IB→ホスト→GPUの3段パイプライン)に対して大きく改善する。Sandy Bridge + Kepler K20 + IB FDR構成で、GDR経路のレイテンシは5.37µs、ホスト経由は31.11µsという実測差が報告されている([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 - 一方でGDRのバンド幅はホスト経由ステージングに大きく劣る(同構成でGDR経路865MB/s vs ホスト経由5989MB/s)。この非対称性は、ネットワークアダプタが**GPUメモリを読み取る**方向(GPU→リモート送信)でのみ生じ、書き込む方向(リモート→GPU受信)では生じない([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 - 上記のバンド幅制限は、当時のIntelチップセット(Sandy Bridge EP・WestmereEP)のPCIe P2P read帯域幅の制約に起因すると推測されている。この制約により、GDRを一律に使う設計は大メッセージで既存のホスト経由パイプラインより性能が劣化する([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 ## MPIライブラリでの活用パターン - [[MVAPICH2]]は、この非対称な性能特性に対応するため、小メッセージ(レイテンシ律速)でGDRの低レイテンシ経路を使い、大メッセージ(バンド幅律速)で既存のホスト経由パイプラインへ切り替えるハイブリッド設計を採る。切り替え閾値はレイテンシ試験とバンド幅試験で異なり(それぞれ32KB・8KB)、下層プラットフォームの帯域制限特性に依存する([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 - さらに、送信側はホストへコピーしてP2P readのボトルネックを回避し、受信側はGDRで直接GPUメモリへ書き込む(この方向は制限を受けない)非対称パイプライン設計により、レイテンシとバンド幅の両立を図る手法も提案されている([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 - IB登録はGPUデバイスメモリでもホストメモリと同様にコストが高く、MPIライブラリ側で登録キャッシュを用いて再利用バッファの登録オーバーヘッドを隠蔽する必要がある。GPUデバイスメモリの確保・解放はCUDAライブラリが管理するため、`cudaFree`相当の呼び出しをトラップして解放前に登録解除する対応も必要になる([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 ## 未編纂の観察 - [初出] 2013年時点のGDR初期実装は、レイテンシ改善とバンド幅制限のトレードオフが明確で、MPIライブラリ側でのハイブリッド設計・閾値チューニングが不可欠だった。この非対称性(読み取り方向のみ制限)がPCIeチップセット世代に依存する点は、後年のGPUネットワーキング研究がホスト経由・ホストバイパスの使い分けを議論する際の出発点になりうる([[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]])。 - [MPIライブラリでの活用パターン] GPUDirect RDMAが利用できない環境(2013年当時のOakleyスーパーコンピュータ等)では、GPU-Aware MPIはホストメモリ経由の非同期パイプライン(pack→D2H→RDMA→H2D→unpack)を常時使う設計になる。この場合もpack/unpackとPCIe/ネットワーク転送を重ね合わせることで、GDR非搭載環境なりの性能改善(連続データで最大42%、非連続境界データで最大27.3%)が得られる(Source: [[@2014__TPDS__GPU-Aware MPI on RDMA-Enabled Clusters - Design, Implementation and Evaluation]])。 - [運用] GPU BARへのメモリピニングはミリ秒オーダーで高コストであり、高性能実装には遅延アンピニング(転送完了後もピン状態を保持し再利用に備える)とレジストレーションキャッシュ(64KB境界に丸めたピンダウンキャッシュ)が不可欠([[@2026__NVIDIA__GPUDirect RDMA]])。 - [運用] サードパーティデバイスドライバがGPUページをピンする際は、アクセス取り消し時にNVIDIAカーネルドライバから同期的に呼ばれるコールバックの提供が必須。コールバック内でGPU側アクションを待つとデッドロックしうるため、実装上の注意点になる([[@2026__NVIDIA__GPUDirect RDMA]])。 - [同期] GPUDirect RDMA経由のデータはGPUの緩やかなメモリモデルの外側にあり、CPU起点のCUDA同期・ワーク投入APIだけがBARマッピング越しの操作順序を保証する。明示的な同期なしでは、GPUカーネルがネットワークRDMA書き込みの古いデータや部分書き込みを観測するデータ競合が起こりうる([[@2026__NVIDIA__GPUDirect RDMA]])。 - [Tegra移植] nv-p2p API(nvidia_p2p_get_pages等)はCUDA 13.0でBlackwell世代Tegra SoCを対象外とし、L4T上のOrinのみ継続サポート(ただしCUDA 14.0で削除予定の非推奨)。Thor以降はLinuxアップストリームカーネルのpin_user_pages/dma_map_sgtable等への移行が明示的に推奨されており、ベンダ固有APIからLinux標準APIへの収斂を示す([[@2026__NVIDIA__GPUDirect RDMA]])。 - [InfiniBand連携] [[nvidia-peermem]] カーネルモジュール(CUDA 11.4導入)がMellanox/NVIDIA InfiniBand系HCAにGPUメモリへの直接P2Pアクセスを付与し、GPUDirect RDMAをInfiniBandファブリック上で実際に有効化する実装コンポーネントとなる([[@2026__NVIDIA__GPUDirect RDMA]])。 - [GDR導入初期(2013年時点)の性能特性] 2014年のIvy Bridge Xeon実測では、ホストメモリ→GPUメモリのwriteはFDR単一レールピーク6.1GB/s(デュアルレール9.8GB/s、ホスト-ホスト間12.3GB/sの約80%)に達する一方、GPUメモリからのread方向は3.4GB/s(GPUクロックブーストで3.7GB/s)にとどまり、read/write間の非対称性は2013年のSandy Bridge/Westmere計測から継続している。(Source: [[@2014__NVIDIA Developer Blog__Benchmarking GPUDirect RDMA on Modern Server Platforms]]) - GPUとIBアダプタをPCIeスイッチ(PLX PEX 8747)経由で直結する構成は、CPU統合ルートコンプレックスに起因するread方向のボトルネックを大きく緩和する: デュアルレールでwrite 11.6GB/s・read 7GB/s(ホスト-ホスト間ピーク12.3GB/sに近い水準)を達成し、ボトルネックの主因がGPU設計ではなくホストプラットフォームのPCIeアーキテクチャにあることを示す。(Source: [[@2014__NVIDIA Developer Blog__Benchmarking GPUDirect RDMA on Modern Server Platforms]]) - [eMTTによるATCキャッシュミス回避] Stellarのextended Memory Translation Table(eMTT)は、RNIC内のMTTにメモリの所有者(Main MemoryかGPUか)を追加記録し、PCIe ATS/ATCによるGDR用アドレス変換のMTT-ATC二段間接参照そのものを廃する構造的解決を採る。CX6 RNICでの検証では、標準ATS/ATC方式はメッセージサイズが2MBを超えるとATCキャッシュミスにより帯域幅が190Gbpsから170Gbpsへ、32MB超では約150Gbpsへ低下するのに対し、eMTT搭載のvStellarはメモリサイズ増加に対して帯域幅が一定に保たれる。2013年時点の知見(本ページのMPIライブラリ活用パターン節)はGDRのIB登録コストをMPIライブラリ側の登録キャッシュで隠蔽するソフトウェア的回避策だったが、eMTTはRNICハードウェア側でキャッシュミスという事象自体を発生させない設計であり、同じ「アドレス変換オーバーヘッド」問題に対する解法のレイヤーが異なる。(Source: [[@2025__SIGCOMM__Alibaba Stellar - A New Generation RDMA Network for Cloud AI]]) ## 未解決の問い - GDRのP2P read帯域幅制限は、その後の世代のPCIe/チップセット(PCIe 4.0以降やNVLink併用構成)でどのように変化したか。 - ハイブリッド設計の切り替え閾値を実行時に自動チューニングする仕組みは、MVAPICH2やその後継でどう実装されたか。 - eMTT方式のRNIC内メモリマッピング容量(MTT自体の物理サイズ)は、仮想デバイス数がさらに増加した場合にどこでスケーリング限界を迎えるか。 ## 関連 - [[RDMA]] - [[InfiniBand]] - [[MVAPICH2]] - ソース: [[@2026__NVIDIA__GPUDirect RDMA]] / [[@2025__SIGCOMM__Alibaba Stellar - A New Generation RDMA Network for Cloud AI]] - 概念: [[nvidia-peermem]] ## 出典 - [[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]] — GDRの初期性能特性の実測とMVAPICH2向けハイブリッド設計を報告。 - [[@2014__TPDS__GPU-Aware MPI on RDMA-Enabled Clusters - Design, Implementation and Evaluation]](GDR非搭載環境でのホスト経由パイプライン設計の性能分析) - [[@2014__NVIDIA Developer Blog__Benchmarking GPUDirect RDMA on Modern Server Platforms]](Ivy Bridge Xeon/PCIeスイッチ構成でのGDR実測バンド幅・レイテンシ)