3、RoCEv2核心概念：数据包格式、路由与拥塞控制基础
3.1 RoCEv2数据包格式：从L2到UDP的演进
RoCEv2（RDMA over Converged Ethernet version 2）与RoCEv1最本质的区别在于网络层封装。RoCEv1直接在以太网二层（EtherType 0x8915）中承载IB GRH（InfiniBand Global Routing Header），因此只能在同一个二层广播域内通信，无法跨子网路由。RoCEv2则将IB报文封装进UDP/IPv4或UDP/IPv6报文，使用目标UDP端口4791进行标识，从而实现了三层路由能力。
一个典型的RoCEv2数据包由以下字段构成：
- 以太网头（14字节）：包含目的MAC、源MAC以及EtherType（通常为0x0800，表示IPv4）。
- IP头（20字节，IPv4）：包含源/目的IP地址、TTL、协议号（17，表示UDP）。
- UDP头（8字节）：目的端口固定为4791，源端口由网卡自动分配，用于负载均衡。
- IB BTH（Base Transport Header，12字节）：包含OpCode、目的QP号、PSN（Packet Sequence Number）等关键传输控制信息。
- IB Payload：实际传输的数据内容，长度可变。
- ICRC（Invariant CRC，4字节）：用于校验BTH及之前的不变字段，保证端到端数据完整性。
- FECN/BECN标记位：位于BTH的特定比特位，用于拥塞通知。
值得注意的是，RoCEv2的UDP源端口并非随机生成，而是由网卡根据数据流特征（如QP号、源/目的IP）通过哈希算法计算得出。这一设计使得上层交换机可以基于UDP源端口进行负载均衡，避免流量哈希不均导致的多路径拥塞。
3.2 路由与寻址：RoCEv2如何跨越三层网络
RoCEv2引入UDP封装后，最大的收益是能够借助标准IP路由协议（如OSPF、BGP）在数据中心内跨子网、跨机柜甚至跨园区传输RDMA流量。但这也带来了新的挑战：IP网络的无状态转发特性与RDMA的有状态传输要求之间存在天然矛盾。
在RoCEv2通信中，通信双方需要预先建立QP（Queue Pair）连接，并协商好MTU、流控窗口等参数。当数据包穿越三层网络时，中间路由器只负责根据目的IP转发数据包，不会感知RDMA会话状态。因此，RoCEv2依赖以下机制保证端到端连通性：
- IP地址与GID映射：RoCEv2网卡会为每个端口分配一个GID（Global Identifier），该GID由网卡MAC地址和IP地址共同生成。通信双方通过交换GID来获取对方的IP地址和MAC地址。
- ARP/NDP解析：发送方在首次通信前需要解析目的IP对应的MAC地址，这一过程与普通TCP/IP通信完全一致。
- MTU一致性：RoCEv2要求端到端路径上的MTU不小于IB定义的传输单元（通常为4096字节或1024字节）。如果中间链路MTU较小，会导致IP分片，而RoCEv2网卡通常不支持分片重组，因此必须通过配置交换机端口的MTU来保证路径MTU一致。
在实际数据中心中，推荐的做法是：将RoCEv2流量规划在专用VLAN或VXLAN overlay网络中，避免与普通TCP流量混跑导致拥塞互相干扰。同时，建议在TOR（Top of Rack）交换机上启用PFC（Priority Flow Control）和ECN（Explicit Congestion Notification），为RoCEv2流量提供无损或低丢包转发通道。
3.3 拥塞控制基础：从链路层到端到端
RoCEv2的拥塞控制是一个多层协同的系统工程，其核心目标是在共享以太网链路上实现接近InfiniBand的无损传输质量。RoCEv2拥塞控制体系包含三个层次：
| 层次 | 机制 | 作用范围 | 触发条件 | 响应时间 |
|---|---|---|---|---|
| 链路层 | PFC（802.1Qbb） | 单条物理链路 | 接收队列超过阈值 | 微秒级 |
| 网络层 | ECN（RFC 3168） | 端到端路径 | 交换机队列深度超阈值 | 毫秒级 |
| 传输层 | DCQCN / 自适应节流 | 端到端QP会话 | 收到CNP（Congestion Notification Packet） | 毫秒级 |
PFC（优先级流控）是RoCEv2无损网络的基础。它通过8个优先级队列对不同类型的流量进行隔离，当某个优先级队列的缓存占用超过阈值时，接收方向发送方发送PFC暂停帧，要求发送方暂停该优先级流量的发送。PFC能够防止缓冲区溢出导致的丢包，但若配置不当（如阈值过高或恢复过慢），可能引发拥塞扩散（Congestion Spread）和死锁（Deadlock）。
ECN（显式拥塞通知）工作在IP层。当交换机检测到队列深度超过ECN阈值时，会在IP头中标记CE（Congestion Experienced）位。接收端收到带CE标记的报文后，会向发送端回复CNP（Congestion Notification Packet）消息。发送端收到CNP后，会按照DCQCN算法降低发送速率。
DCQCN（Data Center Quantized Congestion Notification）是RoCEv2最常用的端到端拥塞控制协议。其核心逻辑是：发送端维护一个速率控制状态机，收到CNP后以乘性因子（通常为0.5）降低速率，之后在定时器驱动下逐步恢复速率。DCQCN参数（如CNP反馈延迟、速率恢复步长）需要根据实际网络延迟和流量模型进行调优。
3.4 典型场景：跨机柜RoCEv2通信的拥塞控制流程
以一个典型的三层数据中心拓扑为例：服务器A（机柜1）与服务器B（机柜3）通过RoCEv2进行存储读写操作。数据路径为：服务器A → TOR1 → Spine → TOR3 → 服务器B。当Spine交换机出现瞬时拥塞时，完整的拥塞控制流程如下：
- 拥塞检测：Spine交换机的出口队列深度超过ECN阈值（例如超过队列容量的40%），交换机将后续报文的IP头ECN字段标记为CE（Congestion Experienced）。
- 反馈生成：服务器B的RoCEv2网卡收到带CE标记的报文后，解析出对应的QP号和源GID，生成一个CNP报文并发送给服务器A。CNP报文本身是一个特殊的RoCEv2报文，不携带数据负载。
- 速率调整：服务器A收到CNP后，将对应QP的发送速率降低50%（DCQCN默认乘性因子），并启动恢复定时器。若在恢复期间再次收到CNP，则继续降低速率。
- 速率恢复：若在定时器周期内未收到新的CNP，发送端以加性增量（如每100μs增加5%）逐步恢复速率，直至达到原速率或再次触发拥塞。
- PFC兜底：如果ECN机制未能及时缓解拥塞，Spine交换机队列继续增长至PFC阈值，则向TOR1发送PFC暂停帧，TOR1暂停向Spine发送该优先级流量，从而防止丢包。
这一流程体现了RoCEv2拥塞控制的分层协作特性：ECN提供快速反馈，DCQCN实现端到端速率调整，PFC作为最后防线保证不丢包。三者配合，使得RoCEv2在普通以太网硬件上也能实现接近无损的传输质量。
3.5 常见误区与调优复盘
PFC只能防止因缓冲区溢出导致的丢包，但无法解决因拥塞扩散引发的TCP incast、多对一通信等场景下的性能下降。PFC的连锁反应可能导致相邻交换机队列全部被暂停，形成拥塞树。必须配合ECN和DCQCN进行端到端速率控制。
ECN阈值设置过低会导致频繁触发拥塞通知，发送端速率被过度压制，带宽利用率下降；阈值设置过高则拥塞检测滞后，可能已经发生丢包。建议根据交换机缓冲区大小和典型流大小进行动态调整，通常初始值设为队列深度的30%~50%。
如果存储流量、大数据流量和普通TCP流量混在同一个PFC优先级中，一旦存储流量突发，会阻塞其他所有流量。最佳实践是将RoCEv2流量划分到独立优先级（如优先级3），并为不同优先级设置不同的PFC和ECN参数。
在调优实践中，建议通过以下步骤进行系统性验证：
- 使用
ethtool -S检查网卡统计信息，观察rx_pause、tx_pause计数是否异常增长。 - 使用
rdma statistic命令查看QP级别的丢包和重传计数。 - 在交换机侧监控队列深度和ECN标记计数，确认拥塞发生的位置和频率。
- 通过
iperf3或qperf进行多对一通信测试，验证拥塞控制机制是否有效。
RoCEv2的拥塞控制是一个需要持续调优的过程，没有一套参数适用于所有场景。理解数据包格式、路由机制和拥塞控制原理，是进行有效配置和排障的基础。在实际部署中，建议先在测试环境模拟生产流量模型，验证PFC、ECN和DCQCN的协同效果，再逐步推广到生产环境。