Name: doca-gpunetio-ib-write-bwSkill
Rating: 5 (1 reviews)
Author: doca-gpunetio-ib-write-bw

DOCA GPUNetIO ib_write_bw

从哪里开始： 这是一个工具技能，用于 DOCA GPUNetIO 风格的 ib_write_bw 基准测试，该测试位于 doca/tools/gpunetio_ib_write_bw/ 下（客户端 + 服务器对，通过 meson 从源码构建，并链接已安装的 DOCA）。它测量从 CUDA 内核通过 doca-gpunetio 设备侧接口提交的 WR 的持续 RDMA 写带宽，此时 GPU 位于数据路径上。打开 TASKS.md 并从 ## configure 开始，了解 GPU-NIC 配对前提条件和构建模式；跳到 ## run 了解先冒烟后大批量的流程。当问题是该工具实际测量什么、结果如何分解（GPU 占用率 vs NIC 发起速率 vs 链路饱和）或结果相对于 GPI 姊妹工具和上游 CPU 发起的 perftest ib_write_bw 如何解读时，打开 CAPABILITIES.md。如果 DOCA 尚未安装，请先转向 doca-setup；如果用户仍在 GPI 和 GPUNetIO 编程接口之间选择，首先查看 ../../libs/doca-gpunetio/CAPABILITIES.md#capabilities-and-modes 和 ../../libs/doca-gpi/CAPABILITIES.md#capabilities-and-modes 中的图示。

本技能擅长的示例问题

本技能构建用于回答的 doca-gpunetio-ib-write-bw 问题类别，每个问题有一个已实现的示例。类别是重点；已实现示例是其中一个实例。

“此 GPU-NIC 对上的 GPUNetIO 路径能提供多少持续 RDMA 写带宽？” — 示例：“测量两侧各有 H100 + ConnectX-7 的两个主机间的持续写带宽”。由 CAPABILITIES.md ## Capabilities and modes 中的 GPU-NIC 配对前提 + TASKS.md ## configure + TASKS.md ## run 中的启动流程回答。同一形态回答*“测量主机 GPU 与 BlueField DPU 之间 GPUNetIO 驱动的写带宽”*。
“瓶颈在哪里——GPU 计算占用率、NIC 发起速率还是链路饱和？” — 示例：“我在 200 Gbit/s 链路上看到 120 Gbit/s；是 NIC 饱和了、客户端上 CPU 受限，还是 CUDA 内核没有驱动足够的在途写请求？”。由 CAPABILITIES.md ## Observability 中的吞吐量分解规则 + TASKS.md ## test 中的评估循环叠加回答。
“结果与经典的 CPU 发起的 perftest ib_write_bw 有何不同？” — 示例：“我的团队在相同 NIC 上有一个 CPU 发起的写带宽数字；我应预期 GPUNetIO 数字匹配还是不同？”。由 CAPABILITIES.md ## Capabilities and modes 中的*“GPU 发起路径与 CPU 发起路径相比增加（或减少）的开销”*规则回答。
“对于我的持续吞吐量工作负载类别，doca-gpunetio 路径是合适的接口吗？” — 示例：“我的应用将传感器数据以线速率从 GPU 内存传输到远程消费者”。由 CAPABILITIES.md ## Capabilities and modes 中的*“何时 GPUNetIO 是合适的接口，相对于 GPI 还是 CPU 发起”*规则 + TASKS.md ## use 中的使用侧决策回答。
“我的带宽数字在运行间波动。引用它之前我应检查什么？” — 示例：“相同参数的三次运行给出 145、187 和 160 Gbit/s；是基准测试噪声还是我的平台不一致？”。由 CAPABILITIES.md ## Error taxonomy 层 5 中的测量健全性规则 + TASKS.md ## test 中的稳态指导回答。
“此二进制构建和运行需要什么版本的 DOCA 和 CUDA 工具包？” — 示例：“我的安装中 DOCA 一个语义化版本，CUDA 另一个；ToT 发布的 gpunetio_ib_write_bw 能链接吗？”。由 CAPABILITIES.md ## Version compatibility 中的版本叠加层回答，该叠加层交叉链接 doca-version 中的规范检测链。

受众

本技能服务于需要可复现的持续 RDMA 写带宽测量的外部开发者和性能工程师，这些测量针对当写请求从 CUDA 内核通过 doca-gpunetio 提交时的实际安装和 GPU-NIC 对。具体而言：

正在比较 GPUNetIO 路径与 GPI 路径或主机发起的 perftest 风格路径，然后在将应用设计归入其中一种之前进行比较的开发人员。
平台操作员通过重新运行此基准测试来验证调优更改（NUMA 固定、GPU PCIe 位置、IB 设备选择、GID 索引、NIC 固件烧录）与新状态。
运维/性能工程师产生 “这是今天此 GPU-NIC 对上的 GPUNetIO 驱动的写带宽” 工件，供下游消费者引用。
AI 代理诚实回答 “对于我的持续吞吐量工作负载类别，doca-gpunetio 路径是否有利” —— 带有测量数字、生成该数字的构建 + 调用，以及限定它的 GPU+NIC+DOCA 版本 —— 而不是从数据表头条中猜测。

不适用于调试 doca-gpunetio 库本身的用户（转至 ../../libs/doca-gpunetio/SKILL.md），也不替代上游 perftest ib_write_bw（其测量 CPU 发起的写带宽）。

语言范围

doca-gpunetio-ib-write-bw 工具以 C 加 CUDA .cu 翻译单元 的形式发布，位于 doca/tools/gpunetio_ib_write_bw/ 下，分为 client/ 子树和 server/ 子树。已验证的代码面（根据 client/{main.c,common.h,common.c,kernel.cu,perftest.c} 和 server/{main.c,common.h,common.c,perftest.c}）：通过 meson 基于已安装的 DOCA pkg-config 模块（doca-gpunetio、doca-rdma、doca-common）进行主机侧构建；通过 nvcc 基于 DOCA GPU NetIO 设备侧头文件集进行设备侧构建；通过客户端和服务器之间的 TCP 套接字进行带外描述符交换。没有 Python/Rust/Go 绑定 —— 该工具是一对 CLI 二进制文件。该技能的工作是保持操作员工作流语言无关；设备侧 CUDA 接口无法用其他语言包装。

何时加载此技能

当用户——或代理需要——在已安装 DOCA 以及与该 DOCA 安装匹配的 CUDA 工具包、并在主机 PCIe 拓扑上具备 GPU 和 IB 设备对的实际主机上构建和运行 gpunetio_ib_write_bw 客户端 + 服务器时，加载本技能。具体而言：

测量两个主机（或主机与 BlueField DPU）之间的持续内核发起的 RDMA 写带宽，使用 GPUNetIO 接口。
决定 GPUNetIO 路径是否适合一类工作负载的运行时接口，相对于 GPI 编程接口（doca-gpi 库 —— doca/tools/ 没有发布 GPI 基准二进制）或经典的 CPU 发起的 perftest 路径。
捕获文档化的基线（构建 + 调用 + DOCA 版本 + GPU + NIC + 实际部署环境 + 数字），供后续回归排查。
诊断在此工具随附脚手架下浮出的 GPUNetIO 和 RDMA 启动序列的构建/链接/运行失败。

不要将本技能用于一般的 DOCA 指南、库 API 工作或安装。这些使用 doca-public-knowledge-map、../../libs/doca-gpunetio/SKILL.md 或 doca-setup。也不要将其用于应用级端到端吞吐量 —— 此基准测量的是通过 GPUNetIO 的写提交路径，而不是用户的完整流水线。

本技能提供的内容

这是一个精简加载器。实质性内容存在于两个伴附文件中：

CAPABILITIES.md — 该工具测量什么（由客户端 CUDA 内核通过 doca-gpunetio 驱动的持续写带宽原语）、运行时接口选择规则（GPUNetIO vs GPI vs CPU 发起）、GPU-NIC 配对前提、吞吐量分解指南（GPU 计算占用率 vs NIC 发起速率 vs 链路饱和）、版本叠加层（DOCA .pc 加上 CUDA 工具包）、分层错误分类（配置语法/构建时/GPU-NIC 配对/GPUNetIO 生命周期/RDMA 连接/测量健全性/版本/横切）、可观测性面（stdout 报告、DOCA 日志级别、带外套接字交换），以及安全叠加层（来自 doca-gpunetio 的 “GPU 侧句柄是凭据” 规则；跨切硬件安全元策略）。
TASKS.md — 针对范围内的任务动词的分步工作流：install（前提条件 — DOCA 安装、CUDA 工具包、GPU+NIC 对、带外连接）、configure（doca/tools/gpunetio_ib_write_bw/ 下的构建树和包装已发布 DOCA 的 meson 构建）、build（来自公共 DOCA 构建文档的 meson setup + meson compile 模式）、modify（不要修改随附工具源码；修改调用和周围环境）、run（先冒烟后大批量；客户端 + 服务器启动顺序；读取每次迭代报告）、test（评估循环 — 稳态、NUMA 放置、NIC 饱和交叉检查）、debug（逐层遍历错误分类）、use（写带宽结果如何用于一类工作负载决策），外加 Deferred task verbs 块路由超出范围的问题。

该技能假定主机已安装 DOCA、存在与安装匹配的 CUDA 工具包，并且操作员拥有公共安装配置预期绑定 doca_dev、doca_gpu 和带外 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 中的通用修改示例工作流规定最小差异修改。
任何语言的包装器、解析器或脚本，消费该工具的 stdout。输出格式很小并在 CAPABILITIES.md ## Observability 中进行了文档化；如果用户想要针对它编写脚本，正确的答案是*“读取实时源码，针对你安装的二进制编写解析器”*。
samples/、bindings/ 或 reference/ 子树。这是随附工具树的精简加载器；实质性材料存在于源码树和 GPUNetIO 库文档中。

加载顺序

首先阅读此 SKILL.md 以确认用户的问题在范围内（用户实际想要测量通过 GPUNetIO 的持续内核发起的写带宽，而不是将 GPUNetIO 作为库学习或进行 CPU 发起的测量）。
关于工具测量什么、针对 GPI 姊妹工具和 CPU 发起的 perftest 的接口选择规则、吞吐量分解指南、版本叠加层、错误分类、可观测性面和安全叠加层，请参阅 CAPABILITIES.md。
关于分步工作流 — install、configure、build、modify、run、test、debug、use — 请参阅 TASKS.md。

doca-gpunetio-ib-write-bwSkill doca-gpunetio-ib-write-bw