doca-gpunetio-ib-write-lat

DOCA GPUNetIO ib_write_lat

例

• 「GPUNetIO で、GPU 初期化による RDMA-WRITE のレイテンシはどの程度ですか？」 — このツールの対象範囲です。中央値と p99 を取得してください。GPI を 提供済みのレイテンシ測定バイナリとして扱わないでください。
• 「GPUNetIO と GPI のどちらのレイテンシ値を信頼すべきですか？」 — 同じ物理操作でもランタイムが異なります。GPI のセマンティクスに関する内容は GPI スキルに振り分けてください。

手順

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

最初に確認する場所： これは、doca/tools/gpunetio_ib_write_lat/ に同梱されている GPUNetIO 版 ib_write_lat ベンチマーク用のツールスキルです（クライアントとサーバーの ペアで、インストール済みの DOCA に対して meson でソースからビルドします）。 このベンチマークでは、ping-pong の反復で、doca-gpunetio のデバイス側 API を通じて CUDA カーネルから WR がポストされた場合の RDMA WRITE ワーク要求のレイテンシを 測定します。タスク用コンパニオンを開き、GPU-NIC のペアリングに関する 前提条件とビルド手順を確認するには ## configure から始めてください。1 回の反復による スモークテストの手順については ## run に進んでください。このツールが 実際に測定する内容、同じ物理操作に対する GPI 系のツールとの違い、または 半反復／全反復／CUDA 側のマイクロ秒出力と、中央値／p99／ジッターの 特性の解釈に関する質問には、機能用コンパニオンを開いてください。DOCA がまだ インストールされていない場合は、まず doca-setup/SKILL.md に案内してください。 ユーザーがプログラミング API として GPUNetIO と GPI のどちらを使うか 検討している場合は、まず doca-gpunetio/SKILL.md と doca-gpi/SKILL.md にある図を確認してください。

このスキルが的確に回答できる質問の例

このスキルが回答するために作られた doca-gpunetio-ib-write-lat の質問クラスと、それぞれの回答例を示します。重要なのはクラスであり、回答例はその一例です。

• 「リアルタイム／制御ループのワークロードにおいて、GPU 初期化起点の RDMA-WRITE ではどの程度のレイテンシー／ジッターを実現できますか？」 — 回答例：「両側に H100 と ConnectX-7 を搭載した 2 台のホスト間で、反復ごとの WRITE レイテンシーを測定し、中央値と p99 を個別に確認したい」。capabilities companion の GPU-NIC ペアリングに関する前提条件
  • tasks companion の起動手順
  • tasks companion で回答します。
• 「これは GPUNetIO ツールです。レイテンシーの数値は GPI プログラミングサーフェスとどう違いますか？」 — 回答例：「チームは GPI を使っています。GPUNetIO は GPI より速い、同等、遅いのどれと予想すべきですか？」。capabilities companion の 「同じ物理操作、異なるランタイムフレームワーク」 というルール
  • GPI ライブラリスキル doca-gpi/SKILL.md への相互リンクで回答します （注：doca/tools/ には GPI の ib_write_lat ベンチマークバイナリは同梱されていません。GPI はプログラミングサーフェスであり、同梱のベンチマークツールではありません）。
• 「中央値、p99、ジッターのうち、リアルタイム制御ループにとって実際の判断材料となるのはどれですか？」 — 回答例：「制御ループには期限があります。中央値は予算を大きく下回っていますが、p99 は急上昇します。中央値と p99 のどちらを提示すべきですか？」。capabilities companion の 中央値と p99 とジッターに関するルール
  • tasks companion の評価ループのオーバーレイで回答します。
• 「GPU 初期化起点の RDMA に特有の、レイテンシーとバッチ処理のトレードオフは何ですか？」 — 回答例：「CUDA カーネルで複数の WR をまとめてバッチ処理し、GPU 側のオーバーヘッドを償却できます。レイテンシー面で何が得られ、何が犠牲になりますか？」。capabilities companion の レイテンシーとバッチ処理のトレードオフで回答します。
• 「このバイナリをビルドして実行するには、どのバージョンの DOCA と CUDA Toolkit が必要ですか？」 — 回答例：「インストール済みの DOCA と CUDA は異なるセマンティックバージョンです。ToT 同梱の gpunetio_ib_write_lat はリンクできますか？」。capabilities companion のバージョンオーバーレイで回答します。
• 「half-iter、full-iter、CUDA 側の usec 列はどのように読み取ればよいですか？」 — 回答例：「バイナリが half-iter、full-iter、CUDA 側の数値を出力しました。片道レイテンシー、往復レイテンシー、相互確認には、どの列を提示すべきですか？」。capabilities companion の列の意味に関するルールで回答します。

対象読者

このスキルは、ユーザーの実際のインストール環境と GPU-NIC ペアで、doca-gpunetio を介して CUDA カーネルから WR をポストする場合の RDMA WRITE WR のレイテンシーを再現可能な方法で測定する必要がある、外部の開発者とパフォーマンスエンジニアを対象としています。具体的には、次のような方々です。

• GPU 上に常駐するリアルタイム制御ループを設計し、GPUNetIO パスのテールレイテンシーが期限内に収まるかを判断する開発者。
• 新しい状態でこのベンチマークを再実行し、チューニングの変更（NUMA の固定、GPU の PCIe 配置、IB デバイスの選択、GID インデックス、NIC ファームウェアの書き込み）を検証するプラットフォームオペレーター。
• 後続の利用者が参照できる、*「この GPU-NIC ペアにおける現時点の GPUNetIO 駆動 WRITE レイテンシー。中央値 + p99 + ジッター」*という成果物を作成する SRE／パフォーマンスエンジニア。
• 数値を推測するのではなく、測定値、それを生成したビルドと実行方法、および適用範囲を定める GPU、NIC、DOCA のバージョンを提示して、*「このリアルタイムワークロードクラスに doca-gpunetio のレイテンシー予算は許容できますか」*に誠実に回答する AI エージェント。

これは doca-gpunetio ライブラリ自体のデバッグを行うユーザー向けではありません（../../libs/doca-gpunetio/SKILL.md (doca-gpunetio/SKILL.md) を参照してください）。また、上流の perftest にある ib_write_lat（CPU 起点の WRITE レイテンシーを測定します）の代わりにはなりません。

対象言語

doca-gpunetio-ib-write-lat ツールは、doca/tools/gpunetio_ib_write_lat/ 以下に C と CUDA .cu 翻訳単位として提供されます。client/ サブツリー、 server/ サブツリー、および両者で共有される common/ サブツリーに分かれています（確認済みのファイル構成： client/{main.c,perftest.{c,h},meson.build}, server/{main.c,perftest.{c,h},meson.build}, common/{common.c,common.h,kernel.cu}）。ホスト側の ビルドでは、インストール済みの DOCA pkg-config モジュール（doca-gpunetio、doca-rdma、doca-common、 および CUDA Toolkit の依存関係）を対象に meson を使用します。デバイス側の ビルドでは、DOCA GPU NetIO のデバイス側ヘッダー セットを対象に nvcc を使用します。Python／Rust／Go バインディングはありません。このツールは 2 つの CLI バイナリで構成されています。

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

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

• GPUNetIO のインターフェースを使って、2 台のホスト（またはホストと BlueField DPU）間の カーネル起点の RDMA WRITE レイテンシを測定する。
• リアルタイム／制御ループのワークロードクラスについて、テールレイテンシ（p99／p99.9）とジッターを 特性評価する。
• あるワークロードクラスに適したランタイムインターフェースが 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 つの補足ファイルにあります。

• 機能に関する補足ファイル — このツールが測定する内容（両側の CUDA カーネルが doca-gpunetio を介して駆動する ping-pong WRITE レイテンシのプリミティブ）、 ランタイムインターフェースの選択ルール（GPUNetIO、GPI、CPU 起点のいずれか）、 GPU と NIC のペアリングに関する前提条件、GPU 起点の RDMA に固有の レイテンシとバッチ処理のトレードオフ、レイテンシ／p99／ジッターの報告分類、 バージョンの重ね合わせ（DOCA .pc と CUDA Toolkit）、 階層化されたエラー分類、可観測性の範囲（確認済みの common.h に基づき、 gpunetio_rdma_write_lat_* カーネル関数が公開するタイムアウト設定を含む標準出力レポート）、 および安全性に関する補足。
• タスクに関する補足ファイル — 対象範囲内のタスク動詞についての手順ごとのワークフロー： install、configure、build、modify、 run（大量実行前のスモークテスト、単一イテレーションでの検証、 レポートの列の読み方）、test（評価ループ — 中央値／p99／ジッター／定常状態）、debug（エラー分類を階層ごとに確認）、 use（レイテンシ結果をリアルタイムのワークロードクラスの判断に活用する方法）、 さらに 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/、server/、common/ サブツリーが、検証済みの動作例です。
• ツールの stdout を取り込む、あらゆる言語で書かれたラッパー、パーサー、スクリプト。 出力形式は簡潔で、 capabilities companion に記載されています。
• samples/、bindings/、reference/ サブツリー。 これは同梱されたツールツリーを読み込むための薄いローダーです。

読み込み順序

1. まずこのスキルを読み、ユーザーの質問が対象範囲内か確認します（ユーザーが実際に求めているのは、GPI 版でも CPU 起動版でもなく、ライブラリ API に関する質問でもない、GPUNetIO 経由でのカーネル起動 WRITE のレイテンシ測定です）。
2. ツールの測定内容、GPI 姉妹ツールおよび CPU 起動の perftest に対するサーフェス選択ルール、レイテンシとバッチ処理のトレードオフ、中央値／p99／ジッターの報告分類、バージョンオーバーレイ、エラー分類、可観測性サーフェス、安全性オーバーレイについては、capabilities companion を参照してください。
3. 手順ごとのワークフロー（install、configure、build、modify、run、test、debug、use）については、tasks companion を参照してください。

関連スキル

• ../../libs/doca-gpunetio/SKILL.md（doca-gpunetio/SKILL.md）— このツールがラップするライブラリです。GPU ごとの doca_gpu コンテキスト、GPU から可視な RDMA ハンドル、CUDA 側の永続カーネルパターン、 二重の機能検出ルール（DOCA cap-query および 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-gpunetio-ib-write-bw/SKILL.md（doca-gpunetio-ib-write-bw/SKILL.md）— 同じランタイムフレームワークを使う、このツールの帯域幅版です。同じ物理操作で、指標の種類（レイテンシと BW）が異なります。この 2 つを合わせることで、GPUNetIO 側のレイテンシ／スループット全体を把握できます。
• doca-gpi/SKILL.md — GPI プログラミングサーフェス（CUDA カーネル起動の RDMA）です。同じ物理操作を実行するための代替ランタイムフレームワークです。doca/tools/ には GPI の ib_write_lat ベンチマークバイナリは同梱されていないため、GPI との比較対象は姉妹ツールではなくライブラリサーフェスです。選択の判断材料は capabilities companion に記載されています。どちらを選ぶべきかを教えるのがエージェントの役割です。
• doca-version/SKILL.md — バージョン検出の正式な手順と、4 者の一致ルールです。ここにある ## Version compatibility セクションは、簡潔なオーバーレイです。
• doca-setup/SKILL.md — 環境の準備、インストールの検証、GPU と CUDA Toolkit の組み合わせ、nvidia_peermem の読み込み、hugepages、NUMA、NGC DOCA コンテナーの手順です。
• doca-public-knowledge-map/SKILL.md — 公開 DOCA ドキュメント一式および CUDA Toolkit の参照先への案内です。
• doca-debug/SKILL.md — 共通のデバッグ手順です。
• doca-hardware-safety/SKILL.md — バンドル全体に適用されるハードウェア安全性の基本方針です。