RDMA无损网络PFC配置与故障排查：从五步配置到死锁恢复

先说一个结论：RDMA无损网络里最容易出幺蛾子的往往不是RDMA协议本身，而是PFC（Priority Flow Control，优先级流控制）。我在机房调了大半年无损配置，最惨的一次是某个训练集群压测时整网吞吐从接近线速掉到几百兆，查了三个通宵，最后发现只是某个中间交换机把RoCEv2的优先级映射弄错了。这篇文章不讲PPT，直接讲把PFC从配置到稳定运行的完整过程，包括五步配置法、死锁排查和一个可落地的巡检清单，适合正在做RoCE集群、存储网络或者AI算力网络的人参考。

1. 为什么RDMA网络必须“无损”：丢包意味着性能崩塌

1.1 一次线上训练故障的复盘

当时我负责一个由40台GPU服务器组成的小集群，用RoCEv2跑分布式训练，交换机都是万兆。最开始没有开PFC，压测时发现只要多机同时读一个存储节点（典型Incast模式），接入交换机的出口瞬间就会饱和。TCP流量还能靠内核重传兜底，RoCE流量直接卡死几分钟，训练任务频繁中断。

后来逐步搞清楚了一件事：RDMA依赖网卡硬件直接读写远端内存，它的传输模型默认网络不会丢包。数据包一旦被丢弃，要么等超时重传，要么触发大量NAK重传风暴。重传风暴会消耗大量CPU中断和带宽，真正的计算任务反而跑不起来。正因如此，RDMA对丢包率的要求通常在1e-9甚至更低，而普通以太网虽然日常丢包率不高，但在突发拥塞场景下远达不到这个量级。

1.2 RDMA丢包的真实代价

很多朋友会把RDMA和TCP混为一谈，觉得“丢包以后有重传就行”，这是最大的认知误区。下面这张对比表可以帮助理解差异：

从这张表就能看出，TCP是“丢包也能凑合活”，RoCEv2是“一旦丢包就崩给你看”。为了保证不丢包，二层网络必须额外提供无损能力，这也是PFC存在的最根本原因。

1.3 PFC在无损网络中的角色

PFC是IEEE 802.1Qbb定义的链路层流量控制协议。它的工作方式很简单：接收端某个优先级的队列占用超过阈值，就向上游设备发送一个pause帧，上游收到后暂停发送该优先级的数据，等水位回落再恢复。注意，PFC是逐跳的背压机制，不是端到端的可靠传输。

PFC解决了“端口buffer溢出导致丢包”的问题，但它也有代价：不会丢包，不代表不会延迟。一个队列被pause住，数据就在路径上积累，整体延迟会上升。因此生产环境里的无损网络一定不是只靠PFC，而是三层配合：

• PFC做最后一层兜底，防止buffer溢出丢包
• 交换机WRED/ECN提前打拥塞标记，让网卡主动降速
• RDMA网卡根据ECN反馈执行DCQCN拥塞控制

三者缺一个，网络都会出问题，但最底层、最容易配错的就是PFC。

2. PFC配置前先想清楚的事：队列、映射与buffer预留

2.1 核心原则：先对齐端网映射，再动交换机

很多人一上来就跑到交换机上敲PFC命令，敲完发现不生效，根本原因是端侧网卡发出的DSCP值、802.1p优先级和交换机内部的队列没有对齐。

以RoCEv2最常用的配置为例：Mellanox/NVIDIA网卡默认使用DSCP 26，推荐映射到802.1p优先级3，交换机上对应队列3开启PFC。在网卡侧可以用rdma qos show link这类命令确认当前生效的DSCP、PFC和ECN配置。只要任何一跳把DSCP映射到别的队列，整条无损链路上的PFC都不会按预期工作。

我踩过最典型的坑是级联场景：接入交换机按DSCP映射到队列3，但汇聚交换机没有开启trust dscp，二层帧里的802.1p优先级被重新打了标签，RoCE流量被丢到普通队列，结果接入交换机一直在发pause帧，汇聚交换机却根本不响应。

2.2 PFC五步配置法

这里给出一套我在多个品牌设备上都验证过逻辑的流程，具体命令语法以你手头设备为准，但步骤顺序千万不要乱：

1. 选定PFC优先级队列，通常取队列3或队列6，整条链路保持一致
2. 在端侧和交换机侧完成DSCP到802.1p到内部队列的映射对齐
3. 在参与RoCE的所有物理端口开启PFC模式，设置为on而不用auto协商
4. 为该队列配置合理的buffer阈值和headroom空间
5. 开启PFC死锁检测与自动恢复

下面这段是“示意配置”，不是直接复制到某品牌设备就能用的，但语义完全一致：

! 交换机侧：以常见设备语义为例，具体命令请查对应手册 interface Ethernet1/1 priority-flow-control mode on trust dscp qos queue 3 pfc enable qos queue 3 pfc headroom 512 KB ! 网卡侧：以RDMA工具为例 rdma qos set link eth2 dscp 26 rdma qos set link eth2 pfc on queue 3 rdma qos set link eth2 ecn enable queue 3

这里重点说两个容易忽略的地方。

第一，PFC模式不要用auto。有些交换机支持自动协商，但无损网络要求两端都确认开启，自动协商失败时设备会偷偷关掉PFC，这种“悄悄退化”非常致命。生产环境我全部显式写死为on。

第二，headroom不能拍脑袋填。headroom是接收端发出pause帧后，对端在收到请求前还能继续发送的数据量。它需要覆盖最差情况下的带宽乘以端到端往返时延，再加上安全余量。如果headroom设太小，突发时照样丢包；设太大，又会吃掉共享buffer，普通流量容易挤爆。

2.3 验收：怎么确认PFC真的生效了

配置完不要急着跑业务，先确认PFC是真的在起作用，还是只是“配置没报错”。我的验收顺序如下：

• 查看交换机各端口PFC暂停帧计数，跑流前后这个计数应该有明显变化
• 查看网卡侧ethtool -S中的rx_prio3_pause_xon/xoff类计数，确认收到了pause帧
• 用多打一压测构造Incast场景，观察端到端吞吐曲线是否稳定
• 重点观察队列drop计数，开启PFC后RoCE优先级的丢包计数应当接近零

如果其他队列的流量丢包突然增多，也别急着怀疑PFC，很有可能是因为headroom挤占了共享buffer，需要回头调整阈值。

3. 配置完就翻车：死锁与反压风暴的完整排查链路

3.1 现象一：流量瞬时归零，恢复时间不定

我第一次在生产集群上正式启用PFC后，业务平稳跑了大概两周，突然有一天所有RoCE流量同时归零，管理面SSH还能通，但训练任务全部卡住。更诡异的是，过几分钟又自己恢复了，没有任何端口报错，TCP却没受影响。

排查时盯着各端口的drop计数，发现全是零；后来切换视角看pause帧统计，才发现队列3的pause帧像洪水一样在几个端口之间来回发送。简单画了数据路径之后真相大白：两条上联链路形成了逻辑环路，队列3的流量在环路里互相pause，最终谁都发不出去，形成PFC死锁。

3.2 现象二：非PFC队列流量被饿死

另一个高频事故是普通流量被“饿死”。有一阵子管理面和存储读流量经常出现高延迟，SSH操作像老年机一样，但RoCE业务本身很稳。查到最后发现，有人把管理流量和RoCE流量都映射到了同一个DSCP 26，管理流量也进了PFC队列3。

这带来的问题很微妙：管理流量本来不使用ECN降速，但它和RoCE挤在同一个队列里，一旦队列被pause，管理流量也跟着停。更要命的是，PFC按优先级暂停，不会区分是业务流量还是管理流量。后面我定了一条铁律：管理、带外、存储和RoCE流量的DSCP必须严格隔离，宁可在交换机上多配几条队列映射规则，也绝不混用。

3.3 排查链路：从错误包计数到队列统计

很多人遇到PFC相关故障会习惯性看接口error、CRC、Oversize，但PFC问题往往一个错误都找不到。完整的排查链路应该是：

1. 先确认是“丢包型故障”还是“暂停型故障”，看队列drop和pause帧计数
2. 查看所有交换节点上每个优先级的pause帧收发计数，定位谁在发pause、谁被pause
3. 画出RoCE所有数据路径，标出可能的环路和故障点
4. 检查PFC死锁检测是否开启，超时时间是否合理
5. 逐步隔离可疑端口，验证故障是否消失

我用的一个笨办法：把故障期间的pause帧计数器按端口拉成曲线，看是“从某个端口扩散出去”还是“全网同时爆”。前者多半是单点反压风暴，后者多半是环路或配置漂移。

3.4 为什么标准协议栈看不出端倪

不少刚接触无损网络的同事会问：Linux的ifconfig里没有报错，怎么网络就不通了？因为PFC的pause帧发生在链路层，IP层和TCP层完全无感，设备状态显示UP，也没有error包。只有专门去数每个优先级的pause帧才能发现问题。

更麻烦的是，PFC死锁恢复前，队列里的数据既不丢也不前进，所有上层超时机制都不起作用。这也解释了我第一次遇到的“流量凭空消失几分钟又恢复”的现象——可能是死锁被某种机制打断，或者队列在超时后自己清空了。所以生产环境一定不能只依赖“自然恢复”，必须主动开启死锁检测。

4. Buffer预算、ECN联动与日常巡检：从“能跑”到“跑得稳”

4.1 buffer预算的计算方法

PFC的headroom不是一个可以随便填的参数，它应该有一个明确的预算推导。可以用下面这个估算公式：

headroom_bytes ≈ (N - 1) × 端口速率 × 最大RTT / 8

其中N是突发方向同时进入的端口数，RTT要取最差情况下的端到端延迟，而不是平均值。

举个例子：8个入端口同时向一个100Gbps出口突发，最大RTT约5微秒，那么headroom大约是：

(8 - 1) × 100Gbps × 5us / 8 = 437.5KB

这还只是理论最小值，实战中我习惯乘以1.5到2的安全系数，再考虑同队列正常通信量的占用，最终为这个队列预留2MB到3MB的buffer空间。问题来了：如果交换机共享buffer一共就十几MB，其他队列的剩余空间会变得很紧张，普通流量在拥塞时更容易丢包。

所以每调一次headroom，都要同时关注非PFC队列的丢包计数。有一次我把某个存储队列的headroom从2MB调到8MB，RoCE流量稳了，但同一个交换机上的监控流量开始频繁丢掉，因为共享buffer被挤没了。这类取舍必须结合业务的实际流量模型来做。

4.2 ECMP和Hash冲突引发的不均衡

PFC只保证“不丢”，但它管不了“均不均”。无损网络里最容易被忽视的问题是ECMP哈希不均衡，多条大流hash到同一条链路时，即便没有丢包，延迟也会很高且触发ECN降速。

调整思路有这么几个：

• 增加RoCE流的数量，让哈希结果更分散
• 使用交换机支持的对称哈希，让双向流落到相同路径
• 把大流和小流适当隔离，避免小流被pause影响
• 关键存储流量走独立物理链路或独立的PFC优先级

我在一个存储集群上把两条100G上联的哈希策略从默认IP五元组改成对称哈希之后，带宽利用率从65%提升到90%，PFC的pause帧数量也下降了一个数量级。这个改动不需要动任何线缆，但效果极其明显。

4.3 ECN与PFC的组合拳

PFC单独使用很容易进入“慢速拥塞”状态：队列没有溢出，但延迟越来越高。ECN的价值就在这里。交换机WRED在队列深度达到阈值时，不再丢弃RoCE包，而是打上CE标记，网卡收到后主动降低发送速率。

我给接入交换机设置的ECN阈值通常是：

• min-threshold设为PFC预留buffer的40%到60%
• max-threshold设为80%到90%
• 标记概率不要用默认的1/100，我一般用1/10，反应更灵敏

这样设计后，正常情况下流量由ECN提前调速，PFC只处理极端突发，全网buffer不会长期被占满。如果只开PFC不开ECN，即使不丢包，也容易碰到“网络没断但性能骤降”的诡异问题。

4.4 常规巡检清单

最后列一份我现在每次变更和每周巡检都会对照的清单，每一条都对应真实的故障经验：

这套巡检脚本我尽量自动化，每五分钟采集一次计数器，设两个告警阈值：PFC死锁计数变化属于高优先级告警，pause帧环比大幅上升属于中优先级告警。第一次踩坑之后，我再也不想靠人肉盯屏发现问题了。

调PFC这段时间我最大的体会是，无损网络不是一次性配置出来的，而是一个不断迭代的工程。后来我每次做变更都带着巡检清单，改PFC阈值的同时会盯普通流量观察至少一周。尤其不要一次把headroom调到最大，风险非常高，最好以500KB到1MB的粒度逐步调整。如果你们也准备上无损网络，建议先在一个小规模环境把PFC计数、死锁检测和ECN联动这套流程跑顺，再去碰生产集群。这些坑提前踩过，后面能少走很多弯路。