第265篇：RoCEv2 拥塞控制与流量监管
关键词
RoCEv2 拥塞控制、DCQCN 调优、ECN 阈值、多流公平性、PFC 风暴、CNP 报文、速率控制
一、拥塞问题的根源
1.1 Incast 问题
Incast（多对一通信）是 RoCEv2 网络中最典型的拥塞场景：
Incast 场景（AI 训练 AllReduce）：
┌──────────┐
│ 参数服务器 │（Receiver）
│ 25Gbps │
└────┬─────┘
│
| ┌──┴──┐ ┌──┴──┐ ┌──┴──┐ | |||||
| GPU1 25G | GPU2 25G | GPU3 25G | ... GPU64 |
64 个 GPU 同时发送数据给参数服务器 接收端：25Gbps 发送端：64 × 25Gbps = 1600Gbps（远超接收能力）
结果： 接收端交换机端口缓存瞬间填满 队列深度急剧增加 ECN 标记 → CNP 反馈 → 发送端减速
1.2 拥塞传播
拥塞传播链（CCL, Congestion Chain Loop）：
次级拥塞（Secondary Congestion）：
发送端 ──► Leaf1 ──► Spine ──► Leaf2 ──► 接收端
│
发往其他 Leaf 的流量也受影响
H2CC（Hashing-based Congestion Chain）：
ECMP 哈希导致不同流共享同一链路
一条流拥塞 → 影响同链路的其他流
PFC 反压传播：
接收端端口拥塞 → PFC 反压到上游 Spine
Spine 端口阻塞 → 反压到其他 Leaf
→ 拥塞从一点扩散到整个网络
二、DCQCN 深度分析
2.1 速率控制算法
DCQCN 的速率调整公式：
收到 CNP 时（减速）：
Rate = Rate × (1 - α / 2)
其中 α 自适应调整：
α = (1 - g) × α + g × F（每次收到 CNP）
g = 滤波因子（默认 1/16）
F = 标记比例（0-1）
没有 CNP 时（恢复）：
每 RateIncreaseTimer（50μs）：
Rate = Rate + β
β 每次增加量（默认 50Mbps）
流量整形效果：
速率
│ ● ← CNP 触发减速
│ ┌──┘
│ ┌──────────┘ ●
│ ● ┌──┘
│ ┌┘ ┌───────────┘ ┌──────
│───┘───┘ └────────→ 时间
● = CNP 接收
折线 = DCQCN 速率控制
体现：快速减速 + 缓慢恢复
2.2 ECN 阈值调优
ECN 阈值直接影响拥塞控制的灵敏度和网络利用率：
ECN 阈值参数：
Kmin（低阈值）：开始标记 CE 的最小队列长度
Kmax（高阈值）：CE 标记概率达到 100% 的队列长度
Pmax：在 Kmax 时的标记概率（通常 100%）
队列长度 vs 标记概率：
标记概率
100% ┤ ┌────────────────
│ ██
│ ██
│ ██
│ ██
0% ┤───────────────→ 队列长度
Kmin Kmax
调优原则：
Kmin 太小 → 过早标记 → 吞吐量下降
Kmin 太大 → 标记太晚 → PFC 被触发（更糟）
Kmax - Kmin 太小 → 标记剧烈 → 速率振荡
推荐初始值（100G 端口）：
Kmin = 100 个报文（~150KB）
Kmax = 400 个报文（~600KB）
缓冲区总量：~1.5MB（头房缓存）
调整方法：
# ECN 阈值配置
ecn-profile ROCE_TUNE
color green
ecn threshold low 200 high 500
ecn mark-probability 100
# 观察 PFC 和 ECN 的比例
display dcb pfc interface 100GE1/0/1
display ecn statistics interface 100GE1/0/1
理想状态：
ECN 标记多（说明拥塞控制正常）
PFC 反压少（说明缓冲足够吸收突发）
不良状态：
ECN 标记少 + PFC 多 → Kmin 太大（需降低）
ECN 标记多 + 吞吐低 → Kmin 太小（需提高）
2.3 多流公平性
多流 RoCE 在拥塞点的公平性问题：
不公平场景：
流 A（GPU1→Receiver）：5Gbps，长流
流 B（GPU2→Receiver）：1Gbps，长流
等待具有相同 ECN 标记
PFC 反压会对所有流一视同仁
→ 流 A 和流 B 被同等对待
→ 流 A 占大带宽，流 B 得不到公平份额
公平性改进：
1. ECN 标记差异化
降低 Kmin → 所有流更早收到反馈
大流收到更多 CNP → 减速更积极
2. DCTCP（Data Center TCP）风格标记
标记概率与队列长度成正比
大流 = 更多 CE 标记 → 更大减速
3. 流量整形（Rate Limiting）
每个 QP（Queue Pair）独立速率控制
防止单个 QP 占用全部带宽
验证公平性：
# 查看各流的速率
display roce statistics qp
display interface 100GE1/0/1 queue statistics
三、PFC 风暴与防护
3.1 PFC 风暴的产生
PFC 风暴（PFC Storm）是无损网络的严重故障：
场景：Leaf 与 Spine 之间的链路拥塞
Leaf1（发送） Leaf2（接收）
│ │
│ PFC Pause Class 3 ───────────►│ ← 队列满
│ │
│ 停止发送 Class 3 │
│ │
│ ← 对上游也发 PFC Pause │
│ │
上游 Spine 也停止发送 │
│ │
更多流受阻... │
│ │
持续 Pause → 检测超时 → 丢包 │
PFC 风暴特征：
1. 连续收到大量 PFC Pause 帧
2. PFC 反压逐级传播
3. 影响面从一点扩散到全网
4. 所有无损流量停滞
3.2 PFC 死锁检测
PFC 死锁检测与恢复机制：
华为 CE 的 PFC 死锁检测：
# 配置 PFC 死锁检测
interface 100GE1/0/1
priority-flow-control dead-detect enable
priority-flow-control dead-detect interval 100 # 100ms 检测周期
priority-flow-control dead-detect count 3 # 3 次连续死锁判定
检测逻辑：
如果某个优先级连续 300ms 处于 Pause 状态
→ 判定为 PFC 死锁
恢复动作：
1. 强制退出 Pause 状态（丢弃部分缓冲报文）
2. 记录告警
3. 通知网管/控制器
查看死锁：
display dcb pfc dead-detect interface 100GE1/0/1
3.3 PFC 配置建议
PFC 防护最佳实践：
1. 只在必要的优先级上开启 PFC
通常只在优先级 3（RoCE）开启
不要在优先级 0（TCP）开启
2. 设置合理的 PFC 阈值
# 华为推荐配置
dcb pfc buffer shared 3000
dcb pfc buffer headroom 1000
dcb pfc buffer xoff-threshold 800
3. 结合 ECN 减少 PFC 触发
ECN 阈值低于 PFC 阈值
ECN 标记先于 PFC 反压触发
典型设置：
ECN 标记：队列 100-400 个报文
PFC 暂停：队列 800+ 个报文
4. 监控 PFC 帧
# 定期检查 PFC 帧数量
# 如果 PFC TX 持续增长 → 存在问题
display dcb pfc interface 100GE1/0/1
四、流量监管与整形
4.1 入方向监管
入方向流量监管（Ingress Policing）：
在 Leaf 入端口限制 RoCE 流的速率：
# 入方向监管
interface 100GE1/0/1（连接 GPU 服务器）
#
qos lr cir 20000 # 限制入方向 20Gbps
#
car car-name roce_car
cir 20000
pir 25000
green pass
yellow pass
red discard
适用场景：
控制单台 GPU 服务器的 RoCE 发送速率
防止某台故障服务器过量发送
多租户带宽保障
4.2 出方向整形
出方向整形（Egress Shaping）：
在 Leaf 出端口对 RoCE 流进行整形：
# 出方向队列整形
interface 100GE1/0/1（连接 Spine）
#
qos queue 3 shaping 80000 # RoCE 队列整形 80Gbps
qos queue 3 wfq weight 40 # 权重
#
qos queue 0 shaping 20000 # 尽力而为 20Gbps
qos queue 0 wfq weight 10
# 层次化 QoS（HQoS）
qos profile HQOS_ROCE
schedule wfq
queue 3 shaping pct 80 # RoCE 占 80% 带宽
queue 0 shaping pct 20 # TCP 占 20% 带宽
适用场景：
出方向带宽保障
确保 RoCE 和其他流量的带宽比例
防止 RoCE 占满所有带宽导致管理不可达
4.3 端到端速率限制
端到端 RoCE 速率限制方法：
方法 1：DCQCN 自适应（推荐）
# 仅配置 ECN + PFC，DCQCN 自动调节
优点：动态自适应，无需手工配置速率
缺点：收敛需要时间
方法 2：QP（Queue Pair）限速
# 限制每个 QP 的速率
roce
qp-rate-limit enable
qp-rate-limit default 10000 # 每个 QP 默认 10Gbps
优点：精确控制每个流
缺点：QP 数量多时配置量巨大
方法 3：UDP 端口探测 + 动态限速
控制器监测各端口 RoCE 流速率
发现异常 → 动态下发限速策略
优点：自动化
缺点：依赖控制器
推荐的做法：
通常使用 DCQCN 自适应速率（方法 1）
AI/HPC 场景可能需要 QP 限速（方法 2）
大规模部署推荐控制器动态调优（方法 3）
五、RoCEv2 性能调优案例
5.1 AI 训练集群调优
场景：256 个 GPU 的 AI 训练集群
网络：Spine-Leaf，100G RoCEv2
问题：训练效率低下，AllReduce 阶段延迟高
排查：
Step 1：查看 PFC 帧计数
display dcb pfc interface 100GE1/0/1
→ PFC Tx 大量增长（> 10000/s）
→ PFC 过于频繁
Step 2：查看 ECN 标记
display ecn statistics
→ ECN 标记很少
→ ECN 阈值设置过高
Step 3：查看队列深度
display qos queue statistics
→ 队列经常达到 800+ 报文
→ 触发 PFC 前没有 ECN 干预
调优：
1. 降低 ECN 阈值
ecn threshold low 80 high 200
2. 调整 Kmin/Kmax
原：Kmin=300, Kmax=800
新：Kmin=80, Kmax=200
3. 增加缓冲区
dcb pfc buffer headroom 1500
效果：
ECN 标记增加 3×
PFC 帧减少 10×
AllReduce 延迟降低 40%
训练吞吐提升 15%
六、总结
| 知识点 | 核心要点 |
|---|---|
| Incast 问题 | 多对一通信导致接收端拥塞，RoCE 常见场景 |
| 拥塞传播 | 次级拥塞 + PFC 反压传播，影响全网 |
| DCQCN 速率控制 | 收到 CNP 减半速，每 50μs 恢复 β |
| ECN 阈值 | Kmin/Kmax 控制标记灵敏度，调试点 |
| 多流公平 | ECN + 独立 QP 速率控制保证公平 |
| PFC 风暴 | 连续 PFC 反压导致全网无损流量停滞 |
| 死锁检测 | 检测连续 Pause，强制恢复 |
| 流量整形 | 入方向监管 + 出方向队列整形 |
七、思考
- Incast 场景中为什么 RoCE 的拥塞控制比 TCP 更加关键？TCP 的 AQM（RED/CoDel）为什么不够？
- ECN 阈值 Kmin 设置得太小或太大会分别导致什么问题？如何根据 PFC 和 ECN 的统计判断 ECN 阈值是否合适？
- PFC 风暴是如何产生的？一个 Leaf 出端口拥塞为什么会导致全网多个 Leaf 受影响？
- DCQCN 中 α 自适应滤波因子 g 的作用是什么？g 设置太大或太小分别有什么影响？
- 在 AI 训练集群中，如果发现 PFC 帧频繁增加（> 10000 帧/秒），但训练吞吐不达标，应该如何调优 ECN 阈值和缓冲区？
下篇预告：第266篇《数据中心 PFC（优先级流控制）死锁故障》——PFC 死锁的根因分析、死锁传播模式、检测恢复机制、最佳实践与故障案例。