Name: GPUNetIOIB写延迟测量Skill
Rating: 5 (1 reviews)
Author: doca-gpunetio-ib-write-lat

许可证：Apache-2.0 名称：doca-gpunetio-ib-write-lat 描述：> 当用户正在测量通过doca-gpunetio由GPU内核发起的RDMA WRITE延迟时，使用此技能——在`doca/tools/gpunetio_ib_write_lat/`下构建并运行`gpunetio_ib_write_lat`客户端+服务器对，检查GPU-NIC配对，读取半迭代/全迭代/CUDA侧usec列，为实时控制回路刻画中位数/99%/抖动，选择GPUNetIO与GPI与CPU发起的`perftest`，或权衡延迟与批处理的取舍。即使没有’GPUNetIO’或’ib_write_lat’也会触发：‘GPU内核RDMA延迟基准’，‘CUDA内核发布WRITE能多快’，‘H100 + ConnectX上的p99 RDMA延迟’，‘内核发起的WR尾延迟’，或’比较GPU发起与CPU发起的perftest’。如果涉及带宽运行（doca-gpunetio-ib-write-bw）、GPI表面（doca-gpi）、库调试（doca-gpunetio）或DOCA安装，请转到其他技能。元数据：类型：工具兼容性：> 要求DOCA SDK安装在Linux（Ubuntu 22.04/24.04或RHEL/SLES）上的/opt/mellanox/doca，并具备支持InfiniBand的ConnectX或BlueField RNIC。要求NVIDIA GPU具备CUDA工具包，并且已加载`nvidia_peermem`；客户端和服务器主机每个都需要在共享的PCIe/NVLink结构上配对GPU-NIC。读取 pkg-config 模块 doca-gpunetio / doca-rdma / doca-common，并针对已安装的DOCA在/opt/mellanox/doca/tools/gpunetio_ib_write_lat的源代码树中构建。

DOCA GPUNetIO ib_write_lat

从哪里开始： 这是一个面向GPUNetIO风格的ib_write_lat基准测试的工具技能，该测试随doca/tools/gpunetio_ib_write_lat/提供（一个客户端+服务器对，通过meson根据已安装的DOCA从源代码构建）。它测量当RDMA WRITE工作请求通过CUDA内核并经doca-gpunetio设备侧接口发布时的延迟，以ping-pong节奏进行。打开TASKS.md并从## configure开始了解GPU-NIC配对前提条件和构建模式；跳转到## run查看单次迭代的冒烟流程。当问题是这个工具到底测量什么、它与同一物理操作上的GPI姊妹工具相比有何不同，或如何解读半迭代/全迭代/CUDA侧usec输出以及中位数/p99/抖动特征时，请打开CAPABILITIES.md。如果DOCA尚未安装，请先转至doca-setup；如果用户仍在决定将GPUNetIO还是GPI作为编程接口，请首先查看../../libs/doca-gpunetio/CAPABILITIES.md#capabilities-and-modes和../../libs/doca-gpi/CAPABILITIES.md#capabilities-and-modes中的对比图。

本技能擅长回答的示例问题

本技能旨在回答的doca-gpunetio-ib-write-lat问题类别，每个带一个实际示例。类别是承重部分；实际示例只是一个实例。

“GPU发起的RDMA-WRITE延迟/抖动在GPUNetIO路径上能为实时/控制回路工作负载提供什么水平？” — 实际示例：“测量两台主机之间的每次迭代WRITE延迟，每台主机配备H100 + ConnectX-7，分别以中位数和p99为目标”。由CAPABILITIES.md ## 能力与模式中的GPU-NIC配对前提 + TASKS.md ## 配置中的启动流程 + TASKS.md ## 运行来回答。
“这是GPUNetIO工具——延迟数字与GPI编程接口有何不同？” — 实际示例：“团队正在使用GPI；我应预期GPUNetIO对GPI是胜出/持平/落后？”。由CAPABILITIES.md ## 能力与模式中的“同一物理操作，不同运行时框架”规则 + 指向GPI库技能的交叉链接../../libs/doca-gpi/CAPABILITIES.md来回答（注意：doca/tools/不附带GPI ib_write_lat基准二进制 — GPI是一种编程接口，不是随附的基准工具）。
“中位数 vs p99 vs 抖动 — 对实时控制回路，哪一个才是真正的答案？” — 实际示例：“我的控制回路有截止期限；中位数远低于预算但p99出现尖峰；我该引用中位数还是p99？”。由CAPABILITIES.md ## 可观测性中的中位数-vs-p99-vs-抖动规则 + TASKS.md ## 测试中的评估循环叠加层来回答。
“针对GPU发起的RDMA，延迟与批处理之间的权衡具体是什么？” — 实际示例：“我的CUDA内核可以批处理多个WR以摊销GPU侧开销；在延迟上这为我带来什么，又需要我付出什么代价？”。由CAPABILITIES.md ## 能力与模式中的延迟-vs-批处理权衡来回答。
“要让这个二进制文件构建并运行，我需要什么版本的DOCA + CUDA Toolkit？” — 实际示例：“我的安装中DOCA是一个semver而CUDA是另一个；ToT随附的gpunetio_ib_write_lat是否甚至能链接？”。由CAPABILITIES.md ## 版本兼容性中的版本叠加层来回答。
“我如何阅读半迭代/全迭代/CUDA侧usec列？” — 实际示例：“二进制打印了半迭代、全迭代和一个CUDA侧数字 — 对于单向延迟 vs 往返 vs 交叉检查，应该引用哪一列？”。由CAPABILITIES.md ## 可观测性中的列语义规则来回答。

受众

本技能服务于需要可重现地测量RDMA WRITE WR（当WR从CUDA内核通过doca-gpunetio发出时）延迟的外部开发人员和性能工程师，针对用户实际安装和GPU-NIC对。具体包括：

正在设计GPU驻留实时控制回路并判断GPUNetIO路径的尾部延迟是否符合截止期限的开发人员。
通过在新状态下重新运行此基准来验证调优更改（NUMA绑定、GPU PCIe位置、IB设备选择、GID索引、NIC固件烧录）的平台运维人员。
生成“这是当前该GPU-NIC对上GPUNetIO驱动的WRITE延迟，包括中位数+p99+抖动”这一制品以供下游消费者引用的SRE/性能工程师。
以诚实态度回答“doca-gpunetio延迟预算对这种实时工作负载类别是否可接受”的AI代理 — 用测量到的数字、产生这些数字的构建+调用方式、以及界定其范围的GPU + NIC + DOCA版本来回答，而不是猜测。

它不适用于调试doca-gpunetio库本身的用户（请转至../../libs/doca-gpunetio/SKILL.md），也不是上游perftest中ib_write_lat（测量CPU发起的WRITE延迟）的替代品。

语言范围

doca-gpunetio-ib-write-lat工具以C及CUDA .cu 编译单元形式提供，位于doca/tools/gpunetio_ib_write_lat/下，划分为一个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}）。主机侧构建使用meson，针对已安装DOCA的pkg-config模块（doca-gpunetio、doca-rdma、doca-common，以及CUDA Toolkit依赖）；设备侧构建使用nvcc，针对DOCA GPU NetIO设备侧头文件集。没有Python / Rust / Go绑定 — 该工具是一对CLI二进制。

何时加载本技能

当用户（或代理需要）在安装有DOCA且CUDA Toolkit与DOCA安装匹配的真实主机上构建并运行gpunetio_ib_write_lat客户端+服务器，且每台主机的PCIe拓扑上具有GPU + IB设备对时，请加载本技能。具体来说：

使用GPUNetIO接口测量两台主机（或主机与BlueField DPU）之间内核发起的RDMA WRITE延迟。
针对实时/控制回路工作负载类别刻画尾部延迟（p99 / p99.9）和抖动。
判断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的WR延迟，而不是用户的完整流水线。

本技能提供什么

这是一个薄加载器。实质性内容包含在两个伴生文件中：

CAPABILITIES.md — 工具测量什么（由两侧CUDA内核通过doca-gpunetio驱动的ping-pong WRITE延迟原语）、运行时接口选择规则（GPUNetIO vs GPI vs CPU发起）、GPU-NIC配对前提条件、GPU发起RDMA固有的延迟-批处理权衡、中位数/p99/抖动报告分类法、版本叠加层（DOCA .pc + CUDA Toolkit）、分层错误分类法、可观测性表面（stdout报告，包括已验证的common.h中gpunetio_rdma_write_lat_*内核函数暴露的超时旋钮），以及安全叠加层。
TASKS.md — 针对范围任务动词的分步工作流：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.md ## 可观测性中记录。
samples/、bindings/或reference/子目录。这是对已提供工具树的薄加载器。

加载顺序

首先阅读此SKILL.md，以确认用户的问题在范围内（用户确实想测量通过GPUNetIO的内核发起WRITE延迟，而非GPI变体，不是CPU发起变体，也不是库API问题）。
关于工具测量什么、与GPI姊妹工具及CPU发起perftest的表面选择规则、延迟-批处理权衡、中位数/p99/抖动报告分类法、版本叠加层、错误分类法、可观测性表面和安全叠加层，请参阅CAPABILITIES.md。
对于逐步工作流 — install、configure、build、modify、run、test、debug、use — 请参阅TASKS.md。

GPUNetIOIB写延迟测量Skill doca-gpunetio-ib-write-lat