📚 课程目录第4章 RoCEv2细节

RoCEv2细节：路由与拥塞控制、流控机制（PFC、ECN）

核心原理：从“二层平铺”走向“三层路由”

RoCEv1只能在二层广播域内传输，依赖以太网帧中的RoCE路由类型字段，无法跨越子网。RoCEv2的最大变化是将IB全局路由头（GRH）替换为UDP/IP头，使RoCE报文成为标准的UDP报文（目的端口4791），从而可以被传统IP网络路由。这一改动让RoCE从“数据中心内部协议”升级为“可跨三层组网协议”，但也引入了新的问题：IP网络的无损保障能力远弱于IB网络，必须依赖额外的流控与拥塞控制机制来弥补。

RoCEv2报文封装结构自上而下为：IB BTH + 原始数据 → UDP头（目的端口4791）→ IP头 → 以太网头。其中UDP源端口由流哈希算法生成，用于在ECMP（等价多路径）中实现负载均衡。值得注意的是，RoCEv2并不使用UDP的校验和做端到端纠错，而是依赖链路层CRC和IB的端到端重传机制。

  关键点：RoCEv2的“路由”能力是牺牲了IB原生无损语义换来的。IP网络默认是“尽力而为”的，丢包后TCP会降速重传，但RoCEv2的RDMA语义不允许随意丢包——一旦丢包，整个QP（队列对）可能进入错误状态，性能断崖式下降。因此，必须引入PFC和ECN来“模拟”无损网络。

PFC（优先级流控）：逐跳的无损保障

PFC（Priority Flow Control，IEEE 802.1Qbb）是RoCEv2无损网络的基础。它将物理链路划分为8个虚拟通道（优先级），每个通道独立进行流控。当接收端某优先级队列的占用超过Xoff阈值时，交换机向对端发送PFC暂停帧，请求对端在指定时间内停止发送该优先级的数据；当队列水位回落到Xon阈值以下时，再发送恢复帧。

PFC的典型配置涉及以下参数：

使能优先级队列：通常为3或4（RoCE专用），与普通TCP流量隔离。
Xoff阈值：触发暂停的队列深度，建议设置为端口缓冲的60%~70%。
Xon阈值：恢复发送的队列深度，通常为Xoff的80%~90%。
暂停时间（quanta）：单次暂停帧覆盖的传输时间，默认65535个quanta（约33ms@10Gbps）。

重要误区：PFC是“逐跳”机制，不是端到端机制。它只保证相邻交换机之间不丢包，但无法感知端到端的拥塞。如果网络中形成“拥塞树”（多个入口流量汇聚到一个出口），PFC可能引发队头阻塞（HOL blocking）和PFC风暴——一个慢速接收者拖慢整个网络。因此PFC必须与ECN配合使用。

ECN（显式拥塞通知）：端到端的拥塞反馈

ECN（Explicit Congestion Notification，RFC 3168）在IP头中利用ECT（ECN-Capable Transport）和CE（Congestion Experienced）两个比特位传递拥塞信号。RoCEv2的ECN工作流程如下：

发送端在IP头中设置ECT位，表明自己支持ECN。
交换机检测到队列深度超过Kmin阈值时，开始以一定概率（与队列深度成正比）将报文IP头中的CE位置1。
接收端收到CE=1的报文后，生成CNP（Congestion Notification Packet），通过RoCEv2的BTH头中的“CNP类型”字段回传给发送端。
发送端收到CNP后，按照DCQCN（Data Center Quantized Congestion Notification）算法降低发送速率，并在恢复阶段逐步提升速率。

DCQCN算法的核心参数包括：

# 典型DCQCN参数（Mellanox推荐值）
# 速率恢复因子（增加速率）
RPG_Increase = 5%  # 每周期增加当前速率的5%
# 速率下降因子（降低速率）
RPG_Decrease = 50% # 收到CNP后速率减半
# 恢复时间（字节计数）
NPTS = 550000      # 无CNP时，每550KB字节恢复一次速率
# 概率分母
PMax = 1.0         # 最大标记概率

案例：典型RoCEv2组网中的流控配置

以下是一个双交换机RoCEv2集群的PFC+ECN配置示例（以Cisco Nexus交换机为例）：

interface Ethernet1/1
  switchport mode trunk
  priority-flow-control mode on
  priority-flow-control priority 3 no-drop   # 优先级3启用无损
  priority-flow-control priority 4 no-drop   # 优先级4启用无损
  qos queue 3 priority 3
  qos queue 4 priority 4

policy-map type network-qos jumbo+ecn
  class type network-qos class-default
    set qos-group 0
    congestion-control ecn   # 启用ECN
    ecn threshold 100 200    # Kmin=100KB, Kmax=200KB

system qos
  service-policy type network-qos jumbo+ecn

配置完成后，可通过以下命令验证PFC和ECN状态：

show priority-flow-control statistics
show queuing interface ethernet 1/1
show hardware qos ecn statistics

误区与复盘：PFC与ECN的协同陷阱

误区/问题	现象	根因	正确做法
只开PFC不开ECN	网络延迟高，TCP流量被饿死	PFC暂停导致TCP队列阻塞，无端到端反馈	PFC+ECN必须同时启用
ECN阈值设置过低	频繁触发CNP，吞吐量下降	Kmin太小，正常突发流量也被标记	Kmin应大于BDP（带宽时延积）
PFC优先级与QoS映射错误	RoCE流量被丢弃	交换机未将RoCE报文映射到no-drop队列	检查DSCP→队列映射一致性
所有优先级都启用PFC	死锁风险，网络瘫痪	多个优先级互相暂停形成环路	仅对RoCE流量启用PFC

复盘建议：在部署RoCEv2时，务必先做小规模验证：用iperf或ib_write_bw打流，同时监控交换机的PFC暂停帧计数和ECN标记计数。如果PFC暂停帧持续增长，说明ECN没有有效抑制拥塞；如果ECN标记过多但吞吐量正常，说明阈值偏保守。理想状态是：ECN承担90%以上的拥塞控制，PFC仅作为最后一道防线。

总结而言，RoCEv2的流控体系是“ECN端到端减速 + PFC逐跳保底”的双层设计。ECN负责在拥塞萌芽时通知发送端主动降速，避免队列溢出；PFC则在ECN来不及响应或出现瞬时突发时，通过暂停帧防止丢包。两者缺一不可，且参数必须根据实际网络拓扑、流量模型和交换机缓冲深度进行调优。理解这一机制，是诊断RoCEv2性能问题（如吞吐量抖动、延迟尖峰、PFC风暴）的基础。