RoCE (RDMA over Converged Ethernet)
核心要点：
- 在标准以太网上实现 RDMA，复用以太网基础设施降低成本
- v2 （UDP/IP 封装） 是当前主流，v1 仅存量
- 无损靠 PFC + ECN 软件配置实现，不像 IB 硬件天然无损
- DCQCN 是主流拥塞控制算法 （ECN + Rate-Based 闭环）
- 比 IB 延迟高 2-3×，但成本约 1/3-1/2
- Meta 24K GPU / 阿里云 / 字节 / 腾讯 / 百度均大规模采用 400GbE RoCEv2
v1 vs v2 的根本差异是什么？
v1 是 L2 （以太网帧），v2 是 L3 (UDP/IP)。差异决定可路由性和多路径能力，见 @tbl-hw-roce-v1-v2。
| 特性 | RoCE v1 | RoCE v2 |
|---|---|---|
| 封装层 | 以太网帧 (L2, EtherType 0x8915) | UDP/IP (L3, UDP dst port 4791) |
| 路由 | 不可路由，仅同一广播域 | 可路由，跨子网 |
| 多路径 | 不支持 | ECMP 等价多路径 |
| 拥塞控制 | PFC 逐跳背压 | PFC + ECN (DCQCN/TIMELY) |
| 主流程度 | 已淘汰，仅存量 | 当前主流，行业标准 |
| 引入年份 | 2010 | 2014 |
@tbl-hw-roce-v1-v2 RoCE v1 vs v2
关键设计：RoCEv2 把 IB 传输层 (BTH, Base Transport Header) 封装在 UDP payload 中，IP 路由设备无需感知 RDMA 语义。5 元组 （源/目的 IP、源/目的端口、协议） 可用于 ECMP 哈希，实现负载均衡。
协议栈长什么样？
应用层与 IB 共用同一套 Verb API，差异只在底层封装和拥塞控制：
应用层 (MPI / NCCL / 存储客户端)
↓
Verb API (ibv_post_send / ibv_poll_cq)
↓
RDMA Provider (libibverbs + rdma-core)
↓
RoCEv2 传输层 (IB BTH + RETH/AETH)
↓
UDP / IP (L3 路由)
↓
以太网 MAC (L2)
↓
25 / 100 / 200 / 400 GbE 物理层
NCCL / OpenMPI / UCX 均通过同一接口同时支持 IB 和 RoCE，应用代码不需修改即可在两种 NIC 间迁移。
RoCEv2 同样支持 RC/UD QP、RDMA Write/Read、Atomic 操作，语义与 IB 一致。
无损以太网怎么实现？
PFC 做链路层背压、ECN 做端到端拥塞感知，两者配合。标准以太网拥塞时直接丢包，RDMA RC 遇到丢包后重传路径走软件，延迟从 us 级飙到 ms 级，必须保证零丢包。
PFC (Priority Flow Control, 802.1Qbb)
工作原理 （逐跳 hop-by-hop 背压）：
- 接收端 （交换机端口或 NIC） 监控各优先级队列水位
- 占用超过 Xon 门限时，向上游发 PAUSE 帧 （含暂停优先级 + 暂停时间）
- 上游收 PAUSE 后停发该优先级数据，直到超时或收到 PFCWD 恢复帧
- RDMA 流量映射到独立优先级 （通常 Priority 3 或 5），与 TCP 流量隔离
PFC 的三个已知问题：
- Head-of-Line Blocking (HOLB)：同优先级内一条流的拥塞 PAUSE 会阻塞同优先级所有流
- PFC Deadlock：多个交换机间形成循环等待，所有方向被 PAUSE，网络永久停顿。需 Watchdog (PFCWD) 定时检测强制恢复
- PAUSE 帧传播放大：背压沿链路向上游传播，可能影响无辜流量
缓解措施：细粒度优先级隔离 + PFCWD + 显式路由规避循环。
ECN (Explicit Congestion Notification)
工作原理 （端到端，RoCEv2 特有）：
- 发送端在 IP 头 ECN 字段标记 ECT （ECN-Capable Transport, 01 或 10）
- 交换机检测队列深度超过 K_min 时，将 ECN 字段改写为 CE (Congestion Experienced, 11)
- 接收端 (RoCEv2 NIC) 收 CE 后向发送端回送 CNP (Congestion Notification Packet)
- 发送端收 CNP 后执行速率降低 （见 DCQCN）
ECN 标记走 RED (Random Early Detection) 变种：
队列深度 < K_min: 不标记 CE
K_min ≤ 队列深度 < K_max: p = (depth - K_min)/(K_max - K_min) × P_max 概率标记
队列深度 ≥ K_max: P_max 概率标记 (通常 P_max = 0.1-1.0)
DCQCN 怎么做拥塞闭环？
ECN 端到端信号 + Rate-Based 发送端速率控制。微软研究院提出，是 RoCEv2 最主流的拥塞控制算法。
降速 (Rate Decrease)
收到 CNP → 记录当前速率 RC
→ 乘性减: RT = RC × (1 - α/2)
→ α 更新: α = α × (1 - g), g 平滑因子 (~0.00390625)
→ 进入 Fast Recovery
首次收 CNP 后速率降约 50% （α 初始值 1）。连续收 CNP 时降幅逐渐减小 （α 递减），避免过度降速。
速率恢复 (Rate Increase)
阶段 1 — Fast Recovery (快速恢复):
每隔 B 字节或 T 时间, RT = (RT + RC) / 2
重复 F 次 (典型 F=5)
阶段 2 — Additive Increase (加性增):
每隔 B 字节或 T 时间, RT = RT + RAI
直到达 Rmax 或收新 CNP
关键参数 (@tbl-hw-roce-dcqcn)
| 参数 | 典型值 | 含义 |
|---|---|---|
| Rmin | 线速 5-10% | 最低速率下限 |
| Rmax | 线速 95-100% | 最高速率上限 |
| K_min / K_max | 100 KB / 200 KB | ECN 标记队列深度门限 |
| P_max | 0.5 | ECN 标记最大概率 |
| T | 55 us | 速率恢复计时器间隔 |
| B | 150 KB | 速率恢复字节计数间隔 |
| F | 5 | Fast Recovery 步数 |
| RAI | 40 Mbps | 加性增步长 |
@tbl-hw-roce-dcqcn DCQCN 关键参数
实际部署需根据集群规模和流量模式调优，配置不当会导致吞吐震荡或收敛缓慢。
TIMELY （替代方案）
Google 提出的基于 RTT 的拥塞控制，不依赖 ECN:
- RTT 增加 → 降速；RTT 稳定 → 恢复
- 优点：无需交换机配置 ECN，部署简单
- 缺点：依赖高精度时钟，对时间戳抖动敏感
- 主要用于 Google 内部；RoCEv2 开源社区主用 DCQCN
与 InfiniBand 的性能差距多大？
RoCEv2 延迟比 IB 高 2-3×，但带宽 / 大消息性能差距 5-10%。对比见 @tbl-hw-roce-vs-ib。
| 指标 | IB NDR | IB HDR | RoCEv2 (200GbE) | RoCEv2 (400GbE) |
|---|---|---|---|---|
| 单端口线速 | 400 Gbps | 200 Gbps | 200 Gbps | 400 Gbps |
| 单向峰值带宽 | ~48 GB/s | ~24 GB/s | ~23 GB/s | ~46 GB/s |
| 小消息延迟 | ~600 ns | ~700 ns | ~1-2 us | ~1-2 us |
| 无损保证 | 硬件信用流控 | 硬件信用流控 | PFC + ECN 软件 | PFC + ECN 软件 |
| 大规模拥塞控制 | ECN + FECN/BECN + SHARP | ECN + FECN/BECN | DCQCN / TIMELY | DCQCN / TIMELY |
| 网内计算 | SHARP （AllReduce 卸载） | SHARP v2 | 无 | 无 |
| 硬件成本 | 高 | 中 | 低 | 中 |
| 配置复杂度 | 中 （SM 统一管理） | 中 | 高 （PFC 调优） | 高 |
| 大规模稳定性 | 成熟 | 成熟 | PFC 死锁风险需管理 | PFC 死锁风险需管理 |
@tbl-hw-roce-vs-ib RoCEv2 vs IB 性能对比
延迟差距分析：
- UDP/IP 封装比 IB LRH/GRH 更长，序列化时间略增
- ECN 反馈回路比 IB 信用流控慢 （需 CNP 往返）
- PFC 暂停期间被暂停的流等待时间不确定
- 以太网交换机 store-and-forward 延迟通常高于 IB 直通 (cut-through)
AI 训练大消息 AllReduce 中带宽是主要瓶颈，RoCEv2 与 IB 大消息性能差距收窄到 5-10%。
AI 集群里怎么用？
节点间承载 PP/DP/EP 通信，节点内仍走 NVLink/HCCS/ICI。
适用场景：
- 规模适中 (<1000 GPU)：交换机数量少，PFC 死锁风险低
- 成本敏感：以太网交换机价格约同等端口 IB 交换机的 1/3-1/2
- 混合流量：同一以太网网络承载 RDMA + 普通 TCP （优先级隔离）
- 存储网络：NVMe-oF over RoCEv2 在 AI 存储系统广泛使用
主要厂商：
- NVIDIA （原 Mellanox） ConnectX 系列：同一 NIC 支持 IB 和 RoCEv2，ConnectX-7 同时支持 NDR IB 和 400GbE RoCEv2
- Marvell FastLinQ：主要面向存储和超融合
- 博通 (Broadcom): Tomahawk / Trident 系列广泛用于 RoCEv2 Spine/Leaf 层
国内云厂商实践：
- 阿里云：自研 RDMA 以太网方案，10万+ GPU 规模集群。精细化 PFC 优先级分离 （RDMA 独占 Priority 3） + 自适应 ECN 门限 + PFCWD 链路级死锁检测 （秒级恢复）
- 华为：iRDMA （基于 RoCEv2 改进），配 iLossless 无损以太网 （HPCC 拥塞控制，基于 INT 精确 RTT 测量）
- 字节跳动 / 腾讯 / 百度：均大规模部署 400GbE RoCEv2，替代 IB 用于 GPU 集群节点间
分工：
节点内 (NVLink / HCCS / ICI):
TP AllReduce — 带宽最优、延迟最敏感
节点间 (RoCEv2 400GbE):
PP P2P — 激活值传递，消息适中
DP AllReduce — 梯度同步，消息大，带宽主导
EP AllToAll — MoE 专家路由，消息分散，延迟敏感
典型集群规格 (400GbE RoCEv2) (@tbl-hw-roce-cluster):
| 层级 | 设备 | 端口规格 | 备注 |
|---|---|---|---|
| 节点 NIC | ConnectX-7 / CX7 | 2×200GbE 或 1×400GbE | 每 GPU 节点 1-2 张 |
| Leaf 交换机 | Tomahawk4/5 | 64×400GbE | 下行连服务器，上行连 Spine |
| Spine 交换机 | Tomahawk5 / Jericho3 | 64-128×400GbE | 核心转发层 |
| 典型集群规模 | — | — | 512-4096 GPU （2 层 fat-tree） |
@tbl-hw-roce-cluster 400GbE RoCEv2 典型集群
部署和运维要注意什么？
5 项必启用网络功能 + 4 类常见问题。
必须启用：
- PFC：为 RDMA 优先级 （如 Priority 3） 启用，关闭其他优先级 PFC 避免 HOLB
- ECN：所有交换机端口和 NIC 启用，配合适 K_min/K_max
- DCQCN 参数：NIC 驱动 (OFED/MLNX_OFED) 配置，与交换机 ECN 门限匹配
- PFCWD：启用 PFC Watchdog，超时 （典型 200ms），检测恢复 PFC 死锁
- QoS 映射：确保 RDMA 流量 DSCP 值正确映射到 PFC 优先级
常见问题 (@tbl-hw-roce-issues):
| 问题 | 根因 | 解决方案 |
|---|---|---|
| 吞吐量 < 线速 50% | DCQCN 参数过激进，过度降速 | 调大 K_min/K_max，减小 P_max |
| 延迟抖动严重 | PFC 暂停时间不稳定，交换机缓冲设置不当 | 增大缓冲区，精调 PFC 水位 |
| PFC 死锁 | 网络拓扑存在环路，PFC 反馈循环 | 启用 PFCWD，检查路由无环 |
| RoCE 连接超时 | ECN 未正确传播，CNP 丢失 | 检查 QoS，确保 CNP 走高优先级 |
@tbl-hw-roce-issues RoCE 常见运维问题
Takeaway
| 知识点 | 核心结论 |
|---|---|
| v1 vs v2 | v1 仅 L2 不可路由已淘汰；v2 UDP/IP 可路由 + ECMP，当前标准 |
| 协议栈 | Verb API 与 IB 兼容，差异在底层封装和拥塞控制 |
| 无损机制 | PFC 链路层背压 + ECN 端到端拥塞感知，两者配合 |
| DCQCN | 收 CNP 乘性减约 50%，恢复分 Fast Recovery + Additive Increase 两阶段 |
| vs IB 延迟 | 高 2-3×，根因：UDP/IP 封装 + ECN 反馈慢 + PFC 不确定性 + 以太网 store-and-forward |
| 国内实践 | 阿里 / 字节 / 腾讯 / 百度 / 华为均大规模 400GbE RoCEv2，替代 IB |
| 运维风险 | PFC 死锁是头号风险，必须配 PFCWD 兜底 |