doca-gpunetio-ib-write-bw

DOCA GPUNetIO ib_write_bw

例

• 「この GPU-NIC ペアで、GPUNetIO はどの程度の持続的な RDMA-WRITE 帯域幅を実現できますか？」 — これは対象範囲内です。gpunetio_ib_write_bw に留まり、ここでは稼働中の GPI アプリを再調整しないでください。
• 「ボトルネックはどこですか？ GPU の占有率、NIC の発行レート、それともリンクの飽和ですか？」 — CUDA カーネルを変更する前に、スループットを要因ごとに分析してください。

手順

以下の読み込み順に従ってください。設定／実行／デバッグについてはタスク用コンパニオンを開いてください。GPU-NIC のペアリングと可観測性については機能用コンパニオンを開いてください。コンパニオンファイルをすべて開く必要はありません。

最初に確認する場所： これは、doca/tools/gpunetio_ib_write_bw/ に含まれる GPUNetIO 版の ib_write_bw ベンチマーク用ツールスキルです（クライアントとサーバーのペアで、インストール済みの DOCA に対して meson でソースからビルドします）。GPU がデータパス上にある状態で、CUDA カーネルから doca-gpunetio のデバイス側インターフェースを介して WR をポストする場合の、持続的な RDMA WRITE 帯域幅を測定します。タスク用コンパニオンを開き、GPU-NIC ペアリングの前提条件とビルド手順については ## configure から確認してください。スモークテストから大量転送へ進む手順については ## run を確認してください。 このツールが実際に測定する内容、結果をどのように要因別（GPU の占有率、NIC の発行レート、リンクの飽和）に分析するか、GPI 系のツールおよび上流の CPU 起点の perftest ib_write_bw と結果をどう比較するか、といった質問については機能用コンパニオンを開いてください。DOCA がまだインストールされていない場合は、まず doca-setup/SKILL.md を参照してください。GPI と GPUNetIO のプログラミングインターフェースのどちらを使うか検討中の場合は、まず doca-gpunetio/SKILL.md と doca-gpi/SKILL.md を確認してください。

このスキルが適切に回答できる質問の例

doca-gpunetio-ib-write-bw に関する質問のクラスと、それぞれの実例を示します。このスキルが回答するよう設計されている質問です。重要なのはクラスであり、実例はその一例です。

• 「この GPU と NIC の組み合わせで、GPUNetIO 経路はどの程度の持続 RDMA-WRITE 帯域幅を実現できますか？」 — 実例： 「両側に H100 と ConnectX-7 を搭載した 2 台のホスト間で、持続 WRITE 帯域幅を測定する」。回答では、機能の補足資料にある GPU-NIC の組み合わせに関する前提条件と、タスクの補足資料にある立ち上げ手順、およびタスクの補足資料を参照します。同じ形式で、*「ホスト GPU と BlueField DPU 間の GPUNetIO による WRITE 帯域幅を測定する」*という質問にも回答できます。
• 「ボトルネックはどこですか。GPU の計算占有率、NIC の発行レート、それともリンクの飽和ですか？」 — 実例： 「200 Gbit/s のリンクで 120 Gbit/s しか出ていません。NIC が飽和しているのか、クライアントが CPU バウンドなのか、それとも CUDA カーネルが十分な数の WR をインフライト状態にできていないのか、どれでしょうか？」。機能の補足資料にあるスループットの分解ルールと、タスクの補足資料にある評価ループのオーバーレイを参照して回答します。
• 「従来の CPU 起動による perftest の ib_write_bw と比べて、結果はどう違いますか？」 — 実例： 「同じ NIC で CPU 起動による WRITE 帯域幅を測定しました。GPUNetIO の数値も同じになると考えるべきですか。それとも異なりますか？」。機能の補足資料にある 「GPU 起動経路では CPU 起動経路と比べてオーバーヘッドが増える（または減る）」 というルールを参照して回答します。
• 「持続スループットを必要とする自分のワークロードクラスには、doca-gpunetio の経路が適していますか？」 — 実例： 「アプリケーションが GPU メモリからリモートのコンシューマーへ、ラインレートでセンサーデータをストリーミングします」。機能の補足資料にある 「GPUNetIO と GPI、CPU 起動経路のうち、どれが適切か」 というルールと、タスクの補足資料にある利用側での判断を参照して回答します。
• 「実行するたびに帯域幅の数値が変わります。引用する前に何を確認すべきですか？」 — 実例： 「同じフラグで 3 回実行したところ、145、187、160 Gbit/s でした。ベンチマークのばらつきが大きいのでしょうか。それともプラットフォームに一貫性がないのでしょうか？」。機能の補足資料の第 5 層にある測定の妥当性に関するルールと、タスクの補足資料にある定常状態についてのガイダンスを参照して回答します。
• 「このバイナリのビルドと実行に必要な DOCA と CUDA Toolkit のバージョンは何ですか？」 — 実例： 「DOCA と CUDA のインストール済みバージョンが異なります。ToT に同梱された gpunetio_ib_write_bw はリンクできますか？」。機能の補足資料にあるバージョンのオーバーレイを参照し、正規の検出手順へのリンクとして doca-version/SKILL.md を確認します。

対象読者

このスキルは、ユーザーが実際に使用しているインストール環境と GPU-NIC の組み合わせで、CUDA カーネルから doca-gpunetio 経由で WR をポストした場合の、持続 RDMA WRITE 帯域幅を再現性のある方法で測定する必要がある 外部開発者とパフォーマンスエンジニアを対象としています。具体的には、次のとおりです。

• アプリケーション設計を決める前に、GPUNetIO 経路を GPI 経路やホスト起動による perftest 形式の経路と比較する開発者。
• 新しい状態でこのベンチマークを再実行し、チューニング変更（NUMA ピニング、GPU の PCIe 配置、IB デバイスの選択、GID インデックス、NIC ファームウェアの書き込み）を検証するプラットフォームオペレーター。
• 下流の利用者が引用できる 「この GPU-NIC の組み合わせで、今日の GPUNetIO による WRITE 帯域幅はこれです」 という成果物を作成する SRE／パフォーマンスエンジニア。
• 「持続スループットを必要とする自分のワークロードクラスで、doca-gpunetio の経路は有効ですか？」 という質問に、データシートの見出しから推測するのではなく、測定値と、それを得たビルド方法および実行方法、さらに測定範囲を定める GPU、NIC、DOCA のバージョンを示して誠実に回答する AI エージェント。

このスキルは、doca-gpunetio ライブラリ自体のデバッグを行うユーザー向けではありません（../../libs/doca-gpunetio/SKILL.md（doca-gpunetio/SKILL.md）を参照してください）。また、CPU 起動による WRITE 帯域幅を測定する、上流の perftest に含まれる ib_write_bw の代替でもありません。

対象言語

doca-gpunetio-ib-write-bw ツールは、doca/tools/gpunetio_ib_write_bw/ に C と CUDA の .cu 翻訳単位として同梱されており、client/ サブツリーと server/ サブツリーに分かれています。検証済みの範囲（client/{main.c,common.h,common.c,kernel.cu,perftest.c} および server/{main.c,common.h,common.c,perftest.c} に基づく）は、インストール済みの DOCA pkg-config モジュール（doca-gpunetio、doca-rdma、doca-common）を使った meson によるホスト側のビルド、DOCA GPU NetIO のデバイス側ヘッダー一式を使った nvcc によるデバイス側のビルド、クライアントとサーバー間の TCP ソケットを介した OOB ディスクリプター交換です。Python／Rust／Go バインディングはなく、このツールは CLI バイナリのペアです。このスキルの役割は、オペレーター側のワークフローを言語に依存しない形に保つことです。デバイス側の CUDA サーフェスは、別の言語でラップできません。

このスキルを読み込むタイミング

ユーザーが、またはエージェントが、DOCA がインストールされ、DOCA のインストールに適合する CUDA Toolkit があり、ホストの PCIe トポロジー上に GPU と IB デバイスのペアがある実機で、gpunetio_ib_write_bw のクライアントとサーバーをビルドして実行する必要がある場合に、このスキルを読み込みます。具体的には、次のような場合です。

• GPUNetIO サーフェスを使って、2 台のホスト（またはホストと BlueField DPU）間で、カーネルが開始する RDMA WRITE の持続帯域幅を測定する。
• ある種のワークロードに対して、GPUNetIO のパスが GPI プログラミングサーフェス（doca-gpi/SKILL.md ライブラリ。doca/tools/ には GPI ベンチマークバイナリはありません）または従来の CPU 開始型 perftest パスと比べ、適切なランタイムサーフェスかどうかを判断する。
• 後日のリグレッション調査に備え、ビルド、起動方法、DOCA のバージョン、GPU、NIC、実環境、測定値を含む、文書化されたベースラインを記録する。
• このツールに同梱されている足場を使った GPUNetIO と RDMA の初期化シーケンスで発生する、ビルド／リンク／実行時のエラーを診断する。

一般的な DOCA の概要、ライブラリ API の作業、インストールについては、このスキルを読み込まないでください。これらについては、doca-public-knowledge-map/SKILL.md、../../libs/doca-gpunetio/SKILL.md（doca-gpunetio/SKILL.md）、または doca-setup/SKILL.md を使用してください。また、アプリケーションレベルのエンドツーエンドのスループットについても、このスキルを読み込まないでください。このベンチマークが測定するのは GPUNetIO 経由の WR 提出パスであり、ユーザーのパイプライン全体ではありません。

このスキルでできること

これは薄いローダーです。実質的な資料は、次の2つの補助ファイルにあります。

• capabilities 補助ファイル — ツールが測定する内容（クライアント側の CUDA カーネルが doca-gpunetio を介して駆動する sustained-WRITE-BW プリミティブ）、実行時サーフェスの選択ルール（GPUNetIO、GPI、CPU 起動のいずれか）、GPU と NIC のペアリングに関する前提条件、スループットの内訳ガイド（GPU 計算の占有率と NIC の発行レート、リンクの飽和度）、バージョンのオーバーレイ（DOCA .pc と CUDA Toolkit の両方）、階層化されたエラー分類（config-syntax / build-time / GPU-NIC-pairing / GPUNetIO-lifecycle / RDMA-connection / measurement-soundness / version / cross-cutting）、可観測性のサーフェス（stdout レポート、DOCA ログレベル、OOB ソケットのやり取り）、および安全性のオーバーレイ（doca-gpunetio における 「GPU 側のハンドルは認証情報である」 というルールと、分野横断的なハードウェア安全性メタポリシー）。
• tasks 補助ファイル — 対象範囲内のタスク動詞に関する手順を追ったワークフロー：install（前提条件 — DOCA のインストール、CUDA Toolkit、GPU と NIC のペア、OOB 接続）、configure（doca/tools/gpunetio_ib_write_bw/ 以下のビルドツリーと、同梱の DOCA をラップする meson ビルド）、build（公開されている DOCA ビルドドキュメントにある meson setup と meson compile のパターン）、modify（同梱ツールのソースにはパッチを適用せず、呼び出し方と周辺環境を変更）、run（一括実行の前にスモークテストを実施すること、クライアントとサーバーの起動順序、反復ごとのレポートの読み方）、test（評価ループ — 定常状態、NUMA の配置、NIC の飽和度のクロスチェック）、debug（エラー分類をレイヤーごとに確認）、use（BW の結果をワークロードのクラスの判断に反映する方法）、および対象範囲外の質問を案内する Deferred task verbs ブロック。

このスキルは、DOCA がすでにインストールされ、インストール内容に対応する CUDA Toolkit があり、doca_dev、doca_gpu、OOB TCP ソケットのバインドに必要な、公開インストールプロファイルが求める権限をオペレーターが持つホストを前提とします。

このスキルに意図的に含めていないもの

このスキルは、サンプルやスクリプトのバンドルではなく、エージェント向けのガイダンスです。境界を明確に保つため、意図的に次のものを含めていません。また、プルリクエストで追加しないでください。

• 具体的なフラグ文字列や想定スループット値 ツールに同梱されている --help と main.c の ARGP 登録から確認できる内容を除きます。フラグの種類は限られています（デバイス名、GPU PCIe アドレス、GID インデックス、クライアント側のサーバー IP）。エージェントはフラグ文字列を引用する前に、インストール済みバージョンのバイナリで --help を再確認します。スループット値はデバイス、ファームウェア、バージョン、トポロジーによって異なります。
• DOCA GPUNetIO または CUDA カーネルの事前作成済みソースコード 同梱ツールのツリーと競合するためです。同梱されている client/{main.c,kernel.cu,perftest.c,common.{c,h}} と server/{main.c,perftest.c,common.{c,h}} が、検証済みの実行例です。エージェントの役割は、ユーザーをそこに案内し、doca-programming-guide/SKILL.md にある普遍的なサンプル変更ワークフローに従って、最小限の差分で変更するよう指示することです。
• ツールの stdout を読み取るラッパー、パーサー、またはスクリプト いずれの言語で記述されたものも含みません。出力形式は小規模で、capabilities 補助ファイルに記載されています。ユーザーがこれを使ったスクリプトを作成したい場合、適切な回答は 「実際のソースを読み、インストール済みのバイナリに合わせてパーサーを書く」 です。
• samples/、bindings/、または reference/ サブツリー これは同梱ツールのツリーを読み込む薄いローダーです。実質的な資料はソースツリーと GPUNetIO ライブラリのドキュメントにあります。

読み込み順序

1. ユーザーの質問が対象範囲内であることを確認するため、まずこのスキルを読みます（ユーザーが実際に求めているのは、GPUNetIO をライブラリとして学ぶことでも、CPU 起点の測定でもなく、カーネル起点の WRITE BW の持続的な測定です）。
2. このツールの測定内容、GPI の姉妹ツールおよび CPU 起点の perftest との使い分けルール、スループット分解ガイド、バージョンオーバーレイ、エラー分類、可観測性の範囲、安全性オーバーレイについては、機能の補足資料を参照してください。
3. install、configure、build、modify、run、test、debug、use の手順については、タスクの補足資料を参照してください。

関連スキル

• ../../libs/doca-gpunetio/SKILL.md (doca-gpunetio/SKILL.md) — このツールがラップするライブラリです。GPU ごとの doca_gpu コンテキスト、GPU から可視な doca_gpu_eth_* および RDMA 側の ハンドル、CUDA 側の永続カーネルパターン、二重の機能検出ルール（DOCA の機能クエリと cudaGetDeviceProperties の両方）、環境の前提条件（nvidia_peermem の読み込み、 DOCA への CUDA バッファーの登録）については、こちらを参照してください。
• ../../libs/doca-rdma/SKILL.md (doca-rdma/SKILL.md) — 基盤となる RDMA ライブラリです。このツールがバインドする RDMA キューは doca-rdma を介して作成、接続されます。キューのライフサイクル、トランスポートタイプ （RC、UC、UD）、権限マトリックス、接続方法は、こちらで扱います。
• ../../libs/doca-verbs/SKILL.md (doca-verbs/SKILL.md) — doca-rdma / doca-gpunetio の下層にある、raw-verbs に切り替えるための手段です。このツールでは 高レベルのインターフェースを使用します。doca-verbs を使うのが適切なのは、 GPUNetIO と RDMA のインターフェースで公開されていない特定の WR フラグや QP 属性が 必要な場合に限られます。
• ../doca-gpunetio-ib-write-lat/SKILL.md (doca-gpunetio-ib-write-lat/SKILL.md) — このツールのレイテンシ版です。物理操作とランタイムフレームワークは同じですが、 メトリックの種類は異なります（BW 対レイテンシ）。この 2 つを組み合わせることで、 GPUNetIO 側のスループットとレイテンシの全体像を把握できます。
• doca-gpi/SKILL.md — GPI の プログラミングインターフェース（CUDA カーネル起点の RDMA）と、同じ物理操作に対する 別のランタイムフレームワークです。doca/tools/ には GPI の ib_write_lat / ib_write_bw ベンチマークバイナリは含まれていないため、GPI との比較対象は 姉妹ツールではなく、ライブラリのインターフェースです。機能の補足資料にある 使い分けルールが判断の手がかりになります。
• doca-version/SKILL.md — バージョン検出の標準的な手順、4 方向の一致ルール、 NGC コンテナーのセマンティクス、ヘッダーをドキュメントより優先するルールについて 説明します。このスキルの ## Version compatibility セクションは簡単な補足です。 本文はこちらにあります。
• doca-setup/SKILL.md — 環境の準備、インストールの検証、GPU と CUDA Toolkit の 組み合わせ、nvidia_peermem の読み込み、hugepages、NUMA、および パブリック NGC DOCA コンテナーを使う「まだインストールしていない」場合の手順に ついて説明します。
• doca-public-knowledge-map/SKILL.md — パブリック DOCA ドキュメント一式（DOCA GPU NetIO、docs.nvidia.com の DOCA RDMA ページ）への案内と、CUDA Toolkit の docs.nvidia.com/cuda/ への参照先を示します。
• doca-debug/SKILL.md — 横断的なデバッグ手順です。このツールには独自のエラー分類が あります。原因が DOCA より下位の層にある場合は、エラー分類からこちらに引き継ぎます。
• doca-hardware-safety/SKILL.md — バンドル全体に適用されるハードウェア安全性の基本方針です。## Safety policy オーバーレイから相互参照しています。