Linux rdma 的 RoCE v2 与 mlx5_core 驱动调优

roce v2流量不通根本原因是无损网络配置缺失，需交换机开启pfc/ecn并与主机mlx5_core参数对齐；port_down常因pfc配置失败；rdma性能低源于队列深度、mtu或内核协议栈干扰；驱动加载失败多因bios pcie设置不当；tcp延迟高则可能由pfc死锁导致。

RoCE v2 流量不通，ibstat 显示端口状态为 PORT_DOWN

根本原因往往不是网卡坏了，而是 RoCE v2 依赖的无损网络基础没配好。交换机必须开启 PFC（优先级流控）和 ECN（显式拥塞通知），且与主机侧的 mlx5_core 驱动参数对齐。

实操建议：

• 先确认交换机端口已启用 PFC 对应 RoCE 的优先级（通常是 priority 3 或 priority 4），并配置了相同的 buffer 分配策略
• 主机侧检查是否启用了对应优先级的 PFC：运行 cat /sys/class/infiniband/mlx5_0/ports/1/pkey_tbl/0 没用，要看 /sys/class/net/enp134s0f0np0/queues/tx-0/byte_queue_limits/hold_time？错——正确路径是 /sys/class/net/enp134s0f0np0/ecn 和 /sys/class/net/enp134s0f0np0/pfc（需内核 ≥ 5.10，且网卡名替换成你实际的 RoCE 接口名）
• 若用 mlnx_ofed 安装驱动，别跳过 mlnx_tune；它会自动设置 devlink dev param set pci/0000:86:00.0 name pfc_enable value true 这类关键参数
• ibstat 显示 PORT_DOWN 时，dmesg | grep mlx5 常见报错是 Failed to configure PFC: Invalid argument——说明驱动尝试下发 PFC 配置失败，大概率是交换机未响应或优先级不匹配

RDMA Write 性能上不去，ib_write_bw 测出来只有 1–3 Gbps

这不是线缆或网卡瓶颈，而是默认队列深度太浅、MTU 太小、或者没绕过内核协议栈。RoCE v2 走的是以太网物理层，但 RDMA 操作必须由用户态库（如 libibverbs）直接调度硬件队列，中间任何内核转发都会拖垮性能。

实操建议：

• 确保使用 ib_write_bw -d mlx5_0 -i 1 -s 1048576 -r 1000 这类大包（-s 1048576）、高重复次数（-r 1000）测试，避免小包噪声干扰
• 检查 MTU：RoCE v2 要求端到端（包括交换机）MTU ≥ 4096；主机侧运行 ip link set dev enp134s0f0np0 mtu 4096，不能只设网卡，交换机 port channel 和 VLAN 接口也得同步改
• 确认没有启用 iptables 或 nftables 规则——哪怕只是 LOG 目标，也会让部分 RoCE 数据包被拉入内核协议栈，导致超时重传
• 用 perf record -e "mlx5:sw_irq" -a sleep 10 看是否频繁触发软件中断；如果出现，说明有大量 Completion Queue (CQ) 事件没被及时轮询，要调大 ibv_create_cq 的 cqe 参数或优化用户态轮询逻辑

mlx5_core 驱动加载失败，dmesg 报 Failed to load FW 或 PCIe link width reduced

这两个错误表面是固件或链路问题，实际多因 BIOS 设置或 PCIe 插槽供电/带宽限制引发。Mellanox ConnectX-5/6 卡对 PCIe Gen3 x16 有硬性要求，降速到 x8 或 Gen2 就会拒绝加载 RoCE 功能。

实操建议：

• 进 BIOS 关闭所有 PCIe ASPM（Active State Power Management）、LTR（Latency Tolerance Reporting）和 SR-IOV（除非真要用），这些功能在某些服务器主板上会导致链路协商异常
• 确认插槽物理支持 x16：有些双槽位主板，第二个 PCIe 插槽实际只连 x8 通道，即使卡插进去，lspci -vv -s 0000:86:00.0 | grep Width 会显示 LnkCap: Port #0, MaxSpeed 8.0GT/s, PhYComplnt 但 LnkSta: Speed 2.5GT/s, Width x8——这就必须换插槽
• FW 加载失败时，别急着重刷固件；先运行 mlxfwmanager --query 看当前 FW 版本，再查 Mellanox FW 兼容矩阵，确认该 FW 是否支持你用的内核版本和 OFED 版本
• 如果用的是 ubuntu 22.04+ 自带的 linux-modules-extra 中的 mlx5_core，注意它可能绑定了旧版固件；建议统一用官方 mlnx-ofed 包，它自带匹配的 fw 和 ko

启用 RoCE v2 后，TCP 流量延迟飙升、丢包增多

这是典型的 PFC 死锁（PFC pause storm）：当交换机某端口因拥塞发 pause 帧，而接收端 RoCE 流量又恰好压满缓冲区，就会把 pause 帧反射回上游，形成环路。TCP 流量虽不直接受 PFC 影响，但共享缓存被 RoCE 占满后，TCP 包就被丢弃。

实操建议：

• 绝对不要给 RoCE 和 TCP 流量混用同一物理接口或同一交换机端口；要么划分独立 VLAN + 独立物理链路，要么用 DCBx 协商严格隔离优先级
• 调小 PFC buffer：在交换机侧将 RoCE 优先级 buffer 从默认 50% 降到 10–20%，同时在主机侧通过 devlink dev param set 调整 buffer_size，避免单个流吃光全部共享缓存
• 启用 ECN 替代纯 PFC：RoCE v2 推荐组合是 PFC + ECN，而非仅 PFC；ECN 能让拥塞信号提前反馈给发送端，减少 pause 帧广播范围
• 监控命令别只看 ibstat：加一条 watch -n1 'cat /sys/class/infiniband/mlx5_0/ports/1/counters/port_xmit_data' | tail -n1，对比 xmit 和 rcv 差值，持续增大说明丢包正在发生

事情说清了就结束。RoCE v2 不是插上线就能跑的“即插即用”技术，它的每个环节——从 BIOS PCIe 设置、交换机 DCB 配置、内核驱动参数，到用户态应用的 CQ 轮询节奏——都存在隐性耦合。漏掉其中一环，表现出来的症状可能完全无关，比如 TCP 延迟高，根源却在 RoCE 的 PFC buffer 配置不当。