Mellanox/NVIDIA ConnectX-6 RoCEv2 中 DCQCN、PFC、ECN 总结1. 背景本次调研对象是一张 Mellanox/NVIDIA ConnectX-6 网卡驱动和固件信息如下driver: mlx5_core version: 23.10-5.1.4 firmware-version: 22.47.1026 bus-info: 0000:09:00.0系统中 RDMA 设备为mlx5_0 mlx5_1对应 netdev 包括enp9s0f0np0 enp9s0f1np1其中enp9s0f0np0当前为主要分析对象。RoCEv2 的拥塞控制通常由三部分组成ECN交换机/网络设备在拥塞时给包打标记 NP接收端 NIC 收到 ECN-marked RoCE 包后发送 CNP RP发送端 NIC 收到 CNP 后执行降速 PFC当队列水位继续升高时按 priority 触发 pause作为兜底防丢包机制NVIDIA 文档说明ECN 是 IP 协议扩展可以在不丢包的情况下通知通信端发生拥塞该实现针对 RoCEv2并要求通信路径上的节点都支持 ECN 才能保证可靠工作。2. PFC、ECN、DCQCN 的关系在 RoCEv2 网络中三者不是互相替代而是分层配合。整体链路可以理解为RoCEv2 data packet ↓ 根据 DSCP / PCP / priority 映射进入某个 traffic class ↓ 交换机队列开始拥塞 ↓ ECN threshold 触发交换机对包打 ECN mark ↓ 接收端 NIC 的 NP 看到 ECN mark生成 CNP ↓ 发送端 NIC 的 RP 收到 CNP执行 DCQCN 降速 ↓ 如果队列继续上涨PFC xoff threshold 触发 pause ↓ 如果仍控制失败才可能出现 drop / timeout / retransmission所以可以简单总结为ECN/DCQCN 提前减速 PFC 最后刹车 drop 控制失败PFC 是 hop-by-hop 的流控机制主要目标是避免特定 priority 的队列丢包ECN/DCQCN 是端到端拥塞反馈和速率调节机制。RoCE 依赖拥塞控制和无损以太网特性来工作NVIDIA Cumulus 文档也明确提到 RoCE 依赖 congestion control 和 lossless Ethernet。3. CX6 上 DCQCN 的 sysfs 暴露路径本机没有发现传统路径/sys/class/infiniband/mlx5_0/ports/1/cc_params/实际存在的是 netdev 维度的 ECN/DCQCN 路径/sys/class/net/enp9s0f0np0/ecn/roce_np /sys/class/net/enp9s0f0np0/ecn/roce_rp这说明当前驱动/固件版本下ConnectX-6 的 RoCE DCQCN 参数主要通过 netdev 下的ecn目录暴露而不是通过/sys/class/infiniband/.../cc_params暴露。NVIDIA 文档中也给出了类似的 sysfs 形式/sys/class/net/interface/ecn/protocol/enable/X其中protocol可以是roce_rp或roce_npX是 priority。4. 本机 DCQCN RP 状态本机roce_rp路径如下/sys/class/net/enp9s0f0np0/ecn/roce_rp其中包含clamp_tgt_rate clamp_tgt_rate_after_time_inc dce_tcp_g dce_tcp_rtt enable initial_alpha_value rate_reduce_monitor_period rate_to_set_on_first_cnp rpg_ai_rate rpg_byte_reset rpg_gd rpg_hai_rate rpg_max_rate rpg_min_dec_fac rpg_min_rate rpg_threshold rpg_time_resetroce_rp/enable/*输出为enable/0: 1 enable/1: 1 enable/2: 1 enable/3: 1 enable/4: 1 enable/5: 1 enable/6: 1 enable/7: 1结论RoCE RP 对 priority 0-7 全部启用。也就是说发送端收到 CNP 后CX6 可以在所有 priority 上执行 DCQCN reaction 逻辑。RP 的核心含义是RP Reaction Point 作用发送端收到 CNP 后降低发送速率并根据算法逐步恢复。5. 本机 DCQCN NP 状态本机roce_np路径如下/sys/class/net/enp9s0f0np0/ecn/roce_nproce_np/enable/*输出为enable/0: 1 enable/1: 1 enable/2: 1 enable/3: 1 enable/4: 1 enable/5: 1 enable/6: 1 enable/7: 1结论RoCE NP 对 priority 0-7 全部启用。也就是说接收端收到 ECN-marked RoCEv2 packet 后可以在所有 priority 上生成 CNP。NP 的核心含义是NP Notification Point 作用接收端看到 ECN mark 后发送 CNP 给发送端。本机 NP 参数包括cnp_dscp 48 cnp_802p_prio 6 min_time_between_cnps 4含义CNP packet 的 DSCP 48 CNP packet 的 802.1p priority 6 连续 CNP 的最小间隔 4这说明 CNP 控制报文默认会以较高优先级发送。后续需要确认交换机和主机 QoS 映射中DSCP 48 / priority 6 是否被正确处理。6. 本机 QoS / PFC 相关 sysfs 状态本机存在 QoS 目录/sys/class/net/enp9s0f0np0/qos内容包括buffer_size maxrate prio2buffer tc_num其中prio2buffer输出为Priority Buffer 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1说明当前 priority 0-7 全部映射到 buffer 1。buffer_size输出为Port buffer size 1026288 Spare buffer size 786960 Buffer Size xoff_threshold xon_threshold 0 0 0 0 1 214272 121824 101808 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0这说明当前只有 buffer 1 配置了有效 buffer。 buffer 1 size 214272 xoff_threshold 121824 xon_threshold 101808 所有 priority 当前都映射到 buffer 1。xoff_threshold和xon_threshold与 PFC pause 的触发/恢复水位相关但仅看到这些 buffer 信息不能直接证明 PFC 已经 enable。PFC 是否真正启用需要继续通过mlnx_qos -i enp9s0f0np0或dcb pfc show dev enp9s0f0np0确认。NVIDIA 文档说明mlnx_qos是本地主机 QoS 的集中配置工具可用于查看和配置 QoS 映射DCBX 设置也可能由 firmware 或 software 控制。7. 当前状态结论基于目前 sysfs 输出可以得到以下结论项目当前状态结论RDMA devicemlx5_0,mlx5_1CX6 双口设备已识别传统cc_params路径不存在当前驱动不走该路径roce_rp存在支持 DCQCN Reaction Pointroce_rp/enable/0-7全 1发送端 CNP reaction 全 priority 启用roce_np存在支持 DCQCN Notification Pointroce_np/enable/0-7全 1接收端 CNP generation 全 priority 启用cnp_dscp48CNP DSCP 为 48cnp_802p_prio6CNP 802.1p priority 为 6/qos/prio2bufferpriority 0-7 全部到 buffer 1当前 QoS buffer 映射较粗/qos/buffer_sizebuffer 1 有 xoff/xonPFC buffer 水位机制存在PFC enable mask尚未确认需要mlnx_qos或dcb pfc交换机 ECN marking尚未确认需要交换机侧配置和 counters核心判断CX6 主机侧 DCQCN 已暴露且已启用。 PFC buffer 相关机制已暴露。 但 PFC 是否启用、RoCE data traffic 走哪个 priority、交换机是否配置 ECN还需要进一步确认。8. 仍需补充确认的关键点8.1 PFC 是否真正 enable需要执行mlnx_qos -i enp9s0f0np0重点关注PFC configuration Priority trust state dscp2prio mapping prio2tc / tc2prio如果没有mlnx_qos可以执行dcb pfc show dev enp9s0f0np0 dcb app show dev enp9s0f0np0 dcb ets show dev enp9s0f0np0判断目标PFC 是否启用 PFC 开在哪些 priority RoCE data traffic 是否进入 PFC enabled priority8.2 Trust state 是 DSCP 还是 PCPRoCEv2 常见有两种 priority 入口DSCP trust根据 IP DSCP 映射到 priority PCP trust根据 VLAN PCP / 802.1p 映射到 priority需要确认mlnx_qos -i enp9s0f0np0重点看Priority trust state因为本机 CNP 是cnp_dscp 48 cnp_802p_prio 6所以如果 trust state 是 DSCP需要确认 DSCP 48 是否映射到 priority 6如果 trust state 是 PCP需要确认 CNP 的 802.1p priority 6 是否在交换机侧被正确调度。8.3 RoCE data traffic 走哪个 priority目前只能确认 CNP priority 是 6不能确认 RoCE data traffic 走哪个 priority。这点非常关键因为 PFC/ECN/DCQCN 都是按 priority 或 traffic class 发生作用。理想情况下需要明确RoCE data packet - priority X PFC enabled - priority X ECN marking - priority X CNP packet - priority 6常见设计是RoCE data priority 3 CNP priority 6 PFC enabled 3 ECN enabled 3但实际以环境配置为准。8.4 交换机侧 ECN 是否配置主机侧 NP/RP 全部 enable只说明 NIC 能处理 ECN/CNP不代表网络中真的会产生 ECN mark。还需要在交换机侧确认RoCE data priority 对应队列是否开启 ECN ECN threshold 是否低于 PFC xoff threshold PFC 是否开启在对应 priority 交换机 counters 中是否有 ECN marked packets 交换机 counters 中是否有 PFC pause正确顺序应该是ECN mark 先发生 CNP 随后产生 PFC pause 少量或兜底发生 drop 不应发生如果 PFC 先大量触发而 CNP 很少通常说明 ECN/DCQCN 没有提前工作。9. 建议检查命令9.1 DCQCN sysfs 完整 dumpfind /sys/class/net/enp9s0f0np0/ecn -maxdepth 3 -type f -print -exec cat {} \;9.2 QoS / buffer dumpfind /sys/class/net/enp9s0f0np0/qos -maxdepth 2 -type f -print -exec cat {} \;9.3 PFC 配置mlnx_qos -i enp9s0f0np0或dcb pfc show dev enp9s0f0np0 dcb app show dev enp9s0f0np0 dcb ets show dev enp9s0f0np09.4 countersethtool -S enp9s0f0np0 | egrep -i pfc|pause|prio|priority|ecn|cnp|cong|roce|rp|np|mark|discard|drop|timeout|retrans建议压测前后做 diffethtool -S enp9s0f0np0 /tmp/before.stats # run ib_write_bw / incast / nccl-tests ethtool -S enp9s0f0np0 /tmp/after.stats diff -u /tmp/before.stats /tmp/after.stats | egrep -i pfc|pause|prio|ecn|cnp|roce|drop|discard|timeout|retrans9.5 firmware / mlxconfigmst start mlxconfig -d 0000:09:00.0 q | egrep -i ROCE|ECN|PFC|CC|DCQCN|QOS|CNP|DSCP|PRIO|TRUST|DCB重点查ROCE_CC_PRIO_MASK ROCE_CC_ALGORITHM ECN PFC QOSNVIDIA ConnectX-6 Dx 固件文档中列出了ROCE_CC_PRIO_MASK、ROCE_CC_ALGORITHM等非易失配置项。另外NVIDIA ConnectX-6 Dx known issues 中提到某些版本里 congestion control 配置可能存在全局而非 per-priority 生效的问题建议确保mlxconfig ROCE_CC_PRIO_MASK_P$port或 sysfsecn/roce_rp/enable/$port中各 priority 的配置保持一致。你当前roce_rp/enable/0-7全为 1属于比较安全的一致配置。10. 实验验证建议实验 1确认 DCQCN 是否工作准备两台 CX6 RoCEv2 主机通过支持 ECN/PFC 的交换机连接。压测前ethtool -S enp9s0f0np0 /tmp/before.stats运行多流 RoCE 压测例如ib_write_bw -d mlx5_0 -i 1 -x gid_index peer_ip -F或多 client incast。压测后ethtool -S enp9s0f0np0 /tmp/after.stats diff -u /tmp/before.stats /tmp/after.stats | egrep -i ecn|cnp|pause|pfc|drop|discard|roce预期健康现象CNP / ECN 相关 counter 有增长 PFC pause 少量增长或不增长 drop / discard 不增长 吞吐没有剧烈周期性震荡实验 2确认 PFC 是否兜底制造更高压力例如多 client 打单 server。观察tx/rx prio pause 是否增长 增长的是哪个 priority 是否和 RoCE data priority 一致如果 PFC counter 狂涨说明网络已经在频繁硬刹。此时要检查ECN threshold 是否太高 DCQCN 是否没有提前降速 RoCE data priority 是否没进 ECN 队列 交换机 buffer 是否不足实验 3确认 priority 映射是否正确需要把以下信息串起来应用 RoCE traffic 的 DSCP / PCP 主机 trust state DSCP/PCP 到 priority 的映射 priority 到 buffer/TC 的映射 PFC enabled priority ECN enabled queue CNP priority目标是避免这种错配RoCE data 走 priority 3 PFC 开在 priority 4 ECN 开在 priority 0 CNP 走 priority 6 但交换机不保优先级这种错配会导致“看起来都开了但实际不生效”。11. 典型问题判断情况 1CNP 不涨PFC 狂涨可能原因交换机没有对 RoCE priority 开 ECN ECN threshold 高于 PFC threshold RoCE data 没进 ECN 队列 NP 没有收到 ECN-marked packet判断ECN/DCQCN 没提前工作PFC 在硬兜底。情况 2CNP 涨吞吐周期性抖动可能原因DCQCN 参数过激 ECN threshold 太低 incast 压力大 恢复速率过快 降速/升速周期震荡判断DCQCN 工作了但参数和网络水位需要调优。情况 3drop/discard 涨PFC/CNP 不涨可能原因RoCE traffic 没进正确 priority PFC 没 enable 交换机 QoS 没命中 链路或 MTU 异常判断lossless/ECN 链路没有真正覆盖 RoCE traffic。情况 4PFC/CNP 都不涨但性能差可能原因瓶颈不在拥塞控制 可能是 NUMA、PCIe、CPU polling、MTU、GID、QP 参数、CQ moderation、inline、signaled WR 等问题判断不要把所有性能问题都归因于 PFC/ECN/DCQCN。12. 最终结论本机 CX6 当前可以确认1. mlx5_core 驱动已识别 CX6。 2. RDMA 设备 mlx5_0 / mlx5_1 存在。 3. 传统 /sys/class/infiniband/.../cc_params 路径不存在。 4. RoCE ECN/DCQCN 通过 /sys/class/net/enp9s0f0np0/ecn 暴露。 5. roce_rp/enable/0-7 全部为 1。 6. roce_np/enable/0-7 全部为 1。 7. CNP DSCP 为 48CNP 802.1p priority 为 6。 8. QoS buffer 中 priority 0-7 当前全部映射到 buffer 1。 9. buffer 1 配置了 xoff/xon threshold。 10. PFC enable mask 尚未确认需要 mlnx_qos 或 dcb 命令进一步确认。工程上最重要的判断是CX6 host-side DCQCN 已经启用 但完整 RoCEv2 拥塞控制链路是否生效还取决于 PFC priority 是否正确、 RoCE data priority 是否正确、 交换机 ECN/PFC 是否正确、 counters 是否符合预期。推荐下一步优先补充mlnx_qos -i enp9s0f0np0 ethtool -S enp9s0f0np0 | egrep -i pfc|pause|prio|priority|ecn|cnp|cong|roce|rp|np|mark|discard|drop|timeout|retrans mlxconfig -d 0000:09:00.0 q | egrep -i ROCE|ECN|PFC|CC|DCQCN|QOS|CNP|DSCP|PRIO|TRUST|DCB只有把sysfs 配置、QoS/PFC 配置、交换机 ECN 配置、runtime counters四块对齐才能确认 CX6 的 RoCEv2 DCQCN/PFC/ECN 链路真正闭环。