4. PFC（优先级流控）配置与调优
好，咱们来聊聊PFC。这东西说白了，就是无损网络的“交通警察”。没有它，RoCE跑起来就跟早晚高峰没信号灯的路口一样——撞得稀里哗啦。我最早接触PFC是在一个金融客户的数据中心，当时他们做高频交易，丢一个包就是几十万美金的损失。嗯，压力山大。
4.1 PFC工作原理
PFC的全称是Priority Flow Control，优先级流控。它跟传统的802.3x流控不一样。传统流控是一刀切——要停全停，要放全放。PFC则精细得多，它把网络流量分成8个优先级（0-7），每个优先级可以独立做流控。
打个比方：传统流控就像整个商场拉电闸，PFC则是只关掉某个楼层的空调。你想想看，这对RoCE多重要？RoCE流量通常跑在优先级3或5上，普通TCP流量跑在0或1上。PFC可以只暂停RoCE的发送端，不影响其他业务。
具体怎么工作的？看这张流程图：
PFC的核心机制就是“反压”。当接收端的缓冲区快满了，它会发一个PFC暂停帧回去。这个帧里带着两个关键信息：要暂停哪个优先级，以及暂停多长时间（以pause_quanta为单位，一个quanta是512 bit times）。
我在项目中遇到过一个问题：某厂商的网卡对PFC暂停帧的响应时间特别慢，导致缓冲区溢出丢包。后来发现是驱动里的中断合并参数没调好。嗯，细节决定成败。
4.2 PFC死锁问题
PFC死锁，圈内也叫“PFC风暴”或“优先级死锁”。说白了就是：A在等B发数据，B在等C发数据，C又在等A发数据——结果谁都不发，全卡死了。
具体场景是这样的：
- 环路拓扑：数据中心里经常有冗余链路，形成物理或逻辑环路
- 多优先级交织：不同优先级的流量互相依赖
- PFC反压传导：一个节点的反压沿着链路反向传播，形成闭环
举个例子你就明白了。假设有三台交换机连成环：
- Switch A的优先级3缓冲区满了，向Switch B发PFC暂停
- Switch B的优先级3也满了，向Switch C发PFC暂停
- Switch C的优先级3也满了，向Switch A发PFC暂停
- 好了，三个交换机都在等对方释放，谁都不动——死锁了
死锁的后果是什么？整个环路上的RoCE流量全部中断。我见过一个案例，某云厂商的存储集群因为PFC死锁，IO延迟从100微秒飙升到500毫秒，整整持续了3分钟才恢复。那3分钟里，运维同学的手都在抖。
4.3 PFC Watchdog机制
既然死锁这么可怕，那怎么破？PFC Watchdog就是干这个的。
Watchdog的原理很简单：给每个优先级设置一个定时器。如果某个优先级持续收到PFC暂停帧超过一定时间（比如100ms），Watchdog就认为可能发生了死锁，然后强制解除暂停状态。
Watchdog的核心参数：
- detection_time：检测阈值，默认100ms。超过这个时间还在暂停状态，就触发
- recovery_action：恢复动作，可以是“强制恢复”或“端口重启”
- monitor_interval：监控间隔，建议10ms一次
我个人习惯把detection_time设成50ms。为什么？因为正常的PFC暂停不会超过20ms，超过50ms基本就是出问题了。设短一点能更快恢复，但要注意别误触发。
配置示例（以Cisco Nexus为例）：
interface Ethernet1/1
priority-flow-control watch-dog
priority-flow-control watch-dog detection-time 50
priority-flow-control watch-dog recovery-action force-restore
💡 我的经验：Watchdog不是万能的。它只能解决“暂停时间过长”导致的死锁，对于“暂停-恢复-暂停”这种高频震荡，Watchdog可能检测不到。这时候需要配合流量整形一起用。
4.4 PFC阈值配置
阈值配置是PFC调优的重头戏。说白了就是：缓冲区多大开始发暂停帧？发多久？
交换机里每个优先级都有独立的缓冲区。阈值分三种：
| 阈值类型 | 含义 | 推荐值 |
|---|---|---|
| XOFF阈值 | 缓冲区达到此水位时，发送PFC暂停帧 | 缓冲区总大小的60-70% |
| XON阈值 | 缓冲区降到此水位时，发送PFC恢复帧 | 缓冲区总大小的30-40% |
| 丢包阈值 | 缓冲区达到此水位时，直接丢包（兜底保护） | 缓冲区总大小的90-95% |
为什么XOFF要设在60-70%？你想想看，从发送端收到暂停帧到真正停止发送，中间有延迟（链路延迟+处理延迟）。这个延迟里，发送端还会继续发数据。所以缓冲区必须留出足够的“刹车距离”。
我曾经在一个项目中把XOFF设成了80%，结果频繁丢包。后来一算，刹车距离需要15%的缓冲区，80%+15%=95%，已经接近丢包阈值了。改成65%后，问题解决。
配置示例（以华为CloudEngine为例）：
interface 10GE1/0/1
priority-flow-control enable
priority-flow-control priority 3
priority-flow-control buffer-size 1024
priority-flow-control xoff-threshold 65
priority-flow-control xon-threshold 35
priority-flow-control drop-threshold 92
4.5 PFC与流量整形配合
光靠PFC是不够的。你想想看，如果发送端一直以线速发数据，PFC暂停帧只能让它“急刹车”。频繁的急刹车会导致：
- 链路利用率下降（因为暂停期间不传数据）
- 延迟抖动增大（暂停-恢复-暂停的震荡）
- 缓冲区利用率不稳定
流量整形（Traffic Shaping）就是解决这个问题的。它让发送端“平滑”地发送数据，而不是突突突地猛发。
我常用的配合策略是这样的：
- 先做整形，再做PFC：整形把流量削平，PFC只做最后的兜底保护
- 整形速率 = 接收端处理能力 × 0.9：留10%的余量，避免缓冲区积压
- 整形突发大小 = 接收端缓冲区 × 0.5：突发不能太大，否则PFC来不及响应
最佳实践组合：
- 流量整形：限制RoCE流量不超过链路带宽的80%
- PFC XOFF阈值：缓冲区60%
- PFC Watchdog：50ms检测，强制恢复
- ECN（显式拥塞通知）：在缓冲区40%时标记，让发送端主动降速
这套组合拳打下来，我还没见过死锁的。
配置示例（整形+PFC联动）：
# 流量整形配置
policy-map SHAPE_ROCE
class ROCE_TRAFFIC
shape average 80000000 ! 80Gbps整形，假设物理链路100Gbps
priority-flow-control threshold 60
# 接口应用
interface Ethernet1/1
service-policy output SHAPE_ROCE
priority-flow-control mode on
💡 避坑指南：我曾经把整形速率设成跟链路带宽一样（100Gbps），结果PFC频繁触发。后来才意识到，整形只是平滑流量，不能解决瞬时突发。一定要留余量，10-20%比较安全。
最后说一句，PFC调优没有银弹。每个数据中心的环境不一样，流量模型不一样，最佳参数也不一样。我的建议是：先在测试环境跑一周，抓PFC统计计数，看暂停频率和持续时间，再逐步调整。别一上来就改生产环境，血的教训。
公众号:蓝海资料掘金营，微信deep3321