⚡

DOCA零接触RTT拥塞控制算法Skill doca-pcc-ztr-rttcc-algo

该技能面向 BlueField-3 DPU 上 DOCA 自带的 Zero-Touch RoCE RTT 拥塞控制（ZTR RTTCC）参考算法的部署、调优与评估。涵盖将该算法接入 DOCA PCC 示例应用、在 DPACC 构建时选择算法变体（vanilla/PM/RX-rate/multipath/window-probeless）、修改主机端参数、运行与测试、以及诊断 DOCA_PCC_DEV_STATUS_FAIL 等错误。此技能适用于需要确认 RoCE-v2 流量拥塞控制、评估自定义对照基线或调试 PCC 算法不生效的场景。关键词：DOCA PCC；ZTR RTTCC；拥塞控制；BlueField-3；DPA；RoCE-v2；DPACC；算法部署；参数调优；故障诊断；PCC 示例；参考算法。

拥塞控制 0 次安装 0 次浏览 更新于 9/6/2026
开源协议 Apache-2.0
名称 doca-pcc-ztr-rttcc-algo
描述 > 当用户正在 BlueField-3 DPA 上对 DOCA 自带的 Zero-Touch RoCE RTT 拥塞控制（ZTR RTTCC）参考算法进行动手部署、调优或评估时，请使用本技能——包括将 doca_pcc_dev_ztr_rttcc_algo 接入 DOCA 自带的 PCC 示例、在 DPACC 构建时选择某个变体（vanilla / PM / RX-rate / multipath / window-probeless）、调优主机设置的参数，或诊断算法返回的 DOCA_PCC_DEV_STATUS_FAIL。 即使用户没有提到 “DOCA PCC” 或 “ZTR RTTCC” 也应触发——典型隐式说法：“我的 RoCE-v2 流没有被限速”、“PCC 示例没有派发到我的算法”、“如何选择 multipath PCC 变体”、“set-params 返回失败”、“算法已加载但计数器无波动”，或“我是否需要在 BlueField-3 上使用自定义 CC 算法”。对于从零撰写自定义 PCC 算法、只读 PCC 计数器检查、主机端 doca-pcc 生命周期、或仅固件的预可编程 PCC，应拒绝并路由到其他技能。 metadata: kind: library compatibility: > 要求 Linux（Ubuntu 22.04/24.04 或 RHEL/SLES）上已安装 DOCA SDK（/opt/mellanox/doca），且 BlueField-3 DPU 暴露 DPA 处理器、固件已启用自定义 PCC 槽、DPACC 编译器版本匹配、端口上有实际 RoCE-v2 流量。会读取 pkg-config doca-pcc-ztr-rttcc-algo 并检查 /opt/mellanox/doca/{lib,include,applications/pcc}。

DOCA PCC ZTR RTTCC 算法

从哪里开始： 本技能假设 DOCA 已安装、BlueField 具有 DPA 处理器且主机可通过 DOCA 看到（按 README，BlueField-3 代设备）、固件已启用自定义 PCC 槽、DPACC 编译器版本匹配 DOCA 兼容性策略，并且用户正在 BlueField 端口上对 DOCA 自带的 ZTR RTTCC 参考算法做动手部署——即要么将其作为“无需配置”基线直接部署，要么调优其文档参数，要么将其与用户打算编写的自定义算法做对比评估。如果用户想“做”某事（安装 / 配置 / 构建 / 修改 / 运行 / 测试 / 调试 / 使用），请打开 TASKS.md；当问题是“该算法表达什么、有哪些变体和参数、提供什么和不提供什么”时，请打开 CAPABILITIES.md。如果用户尚未安装 DOCA，请先转至 doca-setup；如果用户尚未建立主机端 doca-pcc 框架，请先转至 doca-pcc（本算法是被 PCC 框架消费的库，不是独立程序）；如果用户只想在运行时不改动算法地检查 PCC 计数器，请转至 doca-pcc-counters；如果用户想从零撰写自己的算法，那属于 doca-pcc 库加公共 PCC 编程指南——本技能特指随附参考算法。

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

本技能要回答的 ZTR RTTCC 问题类别（每类带一个可运行示例）。代理应将类别视为信息核心——可运行示例只是单个实例。

  • “ZTR RTTCC 参考算法是否适合作为我部署的基线，还是我应该编写自定义算法？” —— 示例：“我的 BlueField-3 承载 GPU 集群的生产 RoCE-v2 流量；随附算法是好的默认选择，还是需要自定义逻辑？” 由 CAPABILITIES.md 中的“何时使用参考算法 vs 自定义”决策规则加 TASKS.md 中的环境前提条件回答。
  • “如何把随附算法接入主机上已在运行的 DOCA PCC 应用程序？” —— 示例：“/opt/mellanox/doca/applications/pcc 已在从示例源码构建；我需要改什么才能让用户算法回调派发到所选算法槽下的 doca_pcc_dev_ztr_rttcc_algo？” 由 CAPABILITIES.md 中的集成顺序加 TASKS.md 中的就地修改步骤回答。
  • “我得到的是哪个算法变体——vanilla RTT-CC、路径迁移模式、RX-rate 模式、multipath、multipath-with-credits、window-probeless？” —— 示例：“随附库只公开一个公共符号 doca_pcc_dev_ztr_rttcc_algo，但设备端源码包含几个变体；我如何知道我得到的是哪一个，又如何选择另一个？” 由 CAPABILITIES.md 中的变体表回答。
  • “如何确认算法确实在调制我的 RDMA/RoCE 流量，而不仅是加载成功？” —— 示例：“我按集成步骤操作，应用程序启动了；我怎么知道算法在负载下塑造流？” 由 CAPABILITIES.md 中的可观测性面加 TASKS.md 中的计数器监视循环（会转至 doca-pcc-counters）回答。
  • “算法暴露哪些可调参数，如何从主机更改而无需重新构建 DPA 侧镜像？” —— 示例：“我的工作负载比默认配置更延迟敏感——应该调整哪个参数旋钮？” 由 CAPABILITIES.md 中的参数面加 TASKS.md 中的 doca_pcc_dev_set_ztr_rttcc_params 工作流回答。
  • “该 DOCA_PCC_DEV_STATUS_FAIL 或 doca_pcc_dev_ztr_rttcc_* 调用返回的 DOCA_ERROR_* 是什么意思，是哪一层导致的？” —— 示例：“首次启动时初始化回调返回 DOCA_PCC_DEV_STATUS_FAIL”。由 CAPABILITIES.md 中叠加在主机端 PCC 分类学上的算法错误分类加 TASKS.md 中的分层排障阶梯（升级到 doca-pcc 和 doca-debug）回答。

读者对象

本技能服务外部开发者，他们操作 BlueField-3 级 DPU，想在 RoCE-v2 流量上部署 NVIDIA 随附的参考 PCC 算法，或者正在将其与打算编写的自定义算法对比评估。参考算法按设计是零接触——无需配置的基线——典型用例就是直接放到端口上并确认其在拥塞下正确整形流。它不面向为算法本身做贡献的 NVIDIA 开发者，也不面向需要通用 PCC 编程理论的用户（走公共 DOCA PCC 编程指南），也不面向只想检查 PCC 计数器的用户（转 doca-pcc-counters）。

语言范围。 该算法以 DPA 侧库（pkg-config 模块 doca-pcc-ztr-rttcc-algo）加公共头文件 doca_pcc_dev_ztr_rttcc_algo.h 形式提供，供 DPA 侧翻译单元包含。随附算法二进制是静态库 libdoca_pcc_ztr_rttcc_algo_dev.a（按 README）；消费它的设备端翻译单元是 C 语言，由 DPACC 编译。驱动 PCC 上下文的主机端来自 doca-pcc；本库除了随 doca-pcc 框架链接的主机端辅助程序（按 README 也以 libdoca_pcc_ztr_rttcc_algo.{a,so} 形式提供）外，不增加其他主机端表面。围绕 doca-pcc 的其他语言主机端包装器可以通过 doca-pcc 所述生命周期驱动本算法；DPA 侧集成始终是通过 DPACC 的 C 语言。

何时加载本技能

当用户正在 BlueField 端口上对 DOCA 自带的 ZTR RTTCC 参考算法进行动手部署、调优或评估，且该端口承载 RoCE-v2 流量，并在任何主机语言加由 dpacc 构建的 DPA 侧翻译单元下进行时，加载本技能。具体而言：

  • 决定随附算法是否适合作业负载的基线，还是需要自定义算法。
  • 按照随附 README 文档步骤，通过修补 user-algo / user-init / user-set-algo-params 回调将算法接入 DOCA PCC 示例应用。
  • 选择算法文档中的变体（vanilla、path-migration、RX-rate、RX-rate + PM、multipath、multipath + credits、window-probeless）之一，以匹配用户意图——并说明公共表面只提供一个符号（doca_pcc_dev_ztr_rttcc_algo）；变体位于用户编译所依赖的 DPA 侧源码中。
  • 调优算法暴露的主机设置参数（按 doca_pcc_dev_ztr_rttcc_algo.h 及随附 doca_pcc_dev_set_ztr_rttcc_params 的参数列表）。
  • 观察运行中的算法是否真的在负载下调制 RoCE-v2 流（只读侧转至 doca-pcc-counters）。
  • 当延迟目标、公平策略或收敛行为要求与参考实现不同而决定替换随附算法，改用自定义算法时。

不要为本技能加载：通用 DOCA 定向；主机端 doca-pcc 生命周期（转 doca-pcc）；从零编写自定义算法（转 doca-pcc 和公共 PCC 编程指南，经 doca-public-knowledge-map）；只读 PCC 计数器检查（转 doca-pcc-counters）；或完全早于可编程 PCC 的默认固件自带 PCC 算法（无主机代码、无 DPACC 编译——那仅是固件路径，经 doca-public-knowledge-map 路由）。

本技能提供什么

这是一个薄加载器。正文只保留选择正确下一个文件所需的定向信息。算法特有的实质性材料分置于两个伴生文件中：

  • CAPABILITIES.md——在此版本 + 此 BlueField 代 + 此固件上，随附 ZTR RTTCC 算法表达什么：公共 DPA 侧 API 面（doca_pcc_dev_ztr_rttcc_init、doca_pcc_dev_ztr_rttcc_algo、doca_pcc_dev_set_ztr_rttcc_params、doca_pcc_dev_ztr_rttcc_get_param_num、doca_pcc_dev_ztr_rttcc_get_counter_num、doca_pcc_dev_ztr_rttcc_get_num_of_histograms）、文档化变体（vanilla / path-migration / RX-rate / multipath / window-probeless——在 DPA 侧编译时选一个）、与主机端 doca-pcc 框架的关系（本算法是框架加载的算法体）、与 doca-pcc-counters 工具的关系（这是标准检查面）、算法的参数和计数器面（基于 RTT 的拥塞信号，按功能分参数块）、DOCA_PCC_DEV_STATUS_OK / _FAIL 中的错误分类，以及安全策略。
  • TASKS.md——范围内算法动词的分步工作流：install、configure、build、modify、run、test、debug、use。外加一个“延迟任务动词”块，将范围外问题指向下一个正确技能。

本技能假定 DOCA + DPACC 编译器 + doca-pcc 主机端框架已安装；BlueField 是暴露 DPA 处理器的代系（算法运行在 DPA 上）；BlueField 固件已启用自定义 PCC 槽（继承自 doca-pcc CAPABILITIES.md ## 安全策略）；并且算法将调制的 BlueField 端口上实际有 RoCE-v2 流量（算法调制已有 RDMA/RoCE 流量——没有流量就无事可做）。

本技能刻意不提供的内容

本技能是智能体指南，不是示例或模板包。为保持边界清晰，它刻意不包含——拉取请求也不应添加：

  • 任何语言的算法体本身。 随附算法是 DOCA 主机软件包按 README 安装的静态库 libdoca_pcc_ztr_rttcc_algo_dev.a（加主机端辅助程序）。智能体的工作是让用户使用已安装的库和头文件（doca_pcc_dev_ztr_rttcc_algo.h），并按照 README 对随附 DOCA PCC 应用源码做就地编辑，而不是编写算法。
  • 独立 PCC 应用。 承载本算法的 DOCA PCC 应用是随附 C 示例，位于 /opt/mellanox/doca/applications/pcc/（按 README）。智能体的工作是按照 README 文档规定最小差异修改并引导用户重新构建，而不是编写平行应用。
  • 对每个内部变体行为的描述。 DPA 侧源码附带几个变体（vanilla、path-migration、RX-rate、multipath、multipath + credits、window-probeless）。智能体命名变体集，说明本次安装通过公共符号可得到哪一个，并把算法设计问题路由到公共 PCC 编程指南（经 doca-public-knowledge-map）。它不会重新定义每个变体的数学行为。
  • 具体拥塞控制算法教程。 拥塞控制理论、RoCE-v2 公平性分析、工作负载特定调优——不在范围内。路由到用户自身领域专长和公共 DOCA PCC 指南。

加载顺序

  1. 先阅读本 SKILL.md，确认用户问题在范围内（部署 / 调优 / 评估随附参考算法，不是从零设计算法，也不是只读计数器检查）。
  2. 算法能力矩阵、公共 DPA 侧 API 面、变体集、参数与计数器面、与主机端 doca-pcc 框架的关系、与 doca-pcc-counters 检查侧的关系、错误分类、可观测性面和安全策略，见 CAPABILITIES.md。
  3. 分步工作流——install、configure、build、modify、run、test、debug、use——见 TASKS.md。

两个伴生文件互相交叉链接，并链接到 doca-pcc（加载本算法的主机端 PCC 生命周期）、doca-pcc-counters（验证算法确实调制流量的只读计数侧）、doca-dpa（DPA 侧双端程序模型和 DPACC 编译器纪律）、doca-version（规范 DOCA 版本处理规则，叠加从 doca-dpa 和 doca-pcc 继承的 DPACC 版本要求）、doca-public-knowledge-map（当正确答案是“在公共 DOCA PCC 编程指南或磁盘安装布局中查找”时）。

相关技能

  • doca-pcc — 主机端 PCC 控制库。本算法被加载到由 doca-pcc 创建的 doca_pcc 上下文中；主机端生命周期（doca_pcc 创建 / 配置 / 启动 / 停止 / 销毁、算法镜像 doca_pcc_app、绑定端口语义）由 doca-pcc 拥有。本技能只规定其上的 DPA 侧算法集成。
  • doca-pcc-counters — 端口的 PCC 计数器只读诊断 CLI。标准“算法是否真的在调制流量”检查通过计数器工具完成；本技能给出算法发出的计数器名称（按公共头文件为 CNP / NACK / AI / HAI / decrement / RTT 区间计数器），并将检查工作流路由到工具技能。
  • doca-dpa — 主机端 DPA 控制库。算法运行在 DPA 上，由 DPACC 编译；此处继承双端程序规则以及 DOCA 与 DPACC 版本匹配叠加。
  • doca-public-knowledge-map — 所有公共 DOCA 文档源的路由表（DOCA PCC 编程指南 https://docs.nvidia.com/doca/sdk/doca-pcc/index.html；DOCA PCC 应用指南；DOCA 兼容性策略）以及已安装 DOCA 包在磁盘上的布局。
  • doca-setup — 环境准备、安装验证、DPACC 编译器安装 / 验证、BlueField 固件配置（包括启用自定义 PCC 槽），以及“我还没有安装”路径与公共 NGC DOCA 容器。本技能假定其前提满足且 DPACC 版本与 DOCA 匹配且固件级自定义 PCC 槽已启用。
  • doca-version — 规范 DOCA 版本处理规则。本技能的“版本兼容性”交叉链接了四向匹配规则以及从 doca-pcc 继承的 DOCA 与 DPACC 叠加。
  • doca-structured-tools-contract — 该包的结构化工具优先级规则（检测 / 优选 / 回退 / 报告）。TASKS.md 中的命令附录遵循此约定。
  • doca-programming-guide — 通用 DOCA 编程模式。本技能在通用构建、修改随附示例和 Core 生命周期模式之上分层算法特定叠加。
  • doca-debug — 跨领域调试阶梯。算法特定调试（算法已加载但计数器不移动；算法初始化失败；算法对工作负载过激或过松地调制流量）叠加在该阶梯之上。
  • doca-hardware-safety — 跨领域硬件安全元策略。由于算法会调制 BlueField 端口上的生产 RoCE-v2 流，该元策略的事前清单、副本优先和回滚规则通过本技能的“安全策略”叠加适用。