📚 课程目录第2章 RoCE基础

2. RoCE基础

2.1 从RDMA到RoCE：为什么需要“绕过内核”的网络传输

传统TCP/IP网络通信中，数据从应用程序发送到网卡，需要经过内核协议栈的多次拷贝、中断处理和上下文切换。以一次典型的10Gbps TCP传输为例，CPU占用率往往超过60%，延迟高达数十微秒。这种“内核参与”的模式在分布式存储、AI训练等场景中成为瓶颈——因为这些场景要求微秒级延迟和极低的CPU开销。

RDMA（Remote Direct Memory Access，远程直接内存访问）的核心思想是：让网卡直接读写远端主机内存，绕过操作系统内核和CPU。发送方应用程序将数据缓冲区地址、长度和目的地址下发给RDMA网卡（HCA，Host Channel Adapter），网卡自行完成数据封装、传输和确认；接收方网卡根据收到的数据直接写入预先注册的内存区域，整个过程CPU几乎不参与。

RDMA有三种主流实现：InfiniBand（IB）、iWARP和RoCE。其中RoCE（RDMA over Converged Ethernet）是最具性价比的方案——它允许在标准以太网基础设施上运行RDMA协议，无需专用IB交换机。RoCE分为两个版本：

RoCEv1：链路层协议，以太网类型字段为0x8915，只能在二层网络内通信，无法跨VLAN或子网。
RoCEv2：基于UDP/IP封装，以太网类型为0x0800（IPv4），目的端口为4791，可路由、可跨三层网络部署，是目前数据中心的主流选择。

关键认知：RoCEv2本质上是“用UDP封装RDMA语义”，它牺牲了IB原生无损网络的确定性，换取了以太网的普适性。因此，RoCEv2对网络质量（尤其是丢包和乱序）极其敏感，这也是ECN水线配置成为核心问题的根源。

2.2 RoCEv2报文格式：逐字段拆解

RoCEv2报文由四层组成：以太网头、IP头、UDP头、InfiniBand BTH+数据。下图展示了报文在传输过程中的封装结构及关键字段。

上图中，DSCP字段是ECN（Explicit Congestion Notification，显式拥塞通知）发挥作用的关键位置。RoCEv2流量通常被标记为DSCP值46（或自定义值），交换机通过队列深度与水线比较，决定是否将IP头中的ECN字段从“ECT”（支持ECN）改为“CE”（拥塞经历）。接收端网卡看到CE标记后，会在RDMA确认报文（ACK）中反馈拥塞信息，发送端据此降速。

2.3 拥塞控制原理：从“丢包反馈”到“ECN反馈”

传统TCP拥塞控制依赖丢包作为拥塞信号——交换机队列溢出后丢弃报文，发送端超时或收到重复ACK后触发拥塞窗口减半。这种方式在RoCE场景中代价极高：一次丢包可能导致RDMA重传超时（通常数百微秒到毫秒级），直接拖垮分布式训练或存储集群的性能。

RoCEv2的拥塞控制采用基于ECN的反馈机制，其核心流程如下：

发送端发出带有ECT标记的RoCEv2报文（IP头ECN字段=01或10）。
交换机监控每个队列的深度。当队列深度超过水线阈值（ECN水线）时，交换机将报文的ECN字段改为CE（值=11），然后正常转发（不丢包）。
接收端收到CE标记的报文后，在返回的ACK中携带拥塞标记（通过CNP，Congestion Notification Packet报文通知发送端）。
发送端收到CNP后，按照DCQCN（Data Center Quantized Congestion Notification）算法降低发送速率，并通过定时器逐步恢复速率。

ECN水线的作用：水线是交换机队列深度的“警戒线”。水线设置过低，交换机过早标记ECN，导致发送端频繁降速，带宽利用率下降；水线设置过高，队列堆积严重，产生较大时延和抖动，甚至可能溢出丢包。理想水线应使队列深度稳定在“刚好填满瓶颈带宽”的水平。

DCQCN算法是RoCEv2拥塞控制的事实标准，其参数包括：

参数	含义	典型值	影响
α	拥塞因子（发送端维护）	初始0.01~0.1	决定降速幅度
Gd	降速因子	1/256	收到CNP后速率乘以(1-Gd)
Gi	增速因子	1/1024	无CNP时周期性恢复速率
NP	CNP发送周期	50μs	接收端反馈拥塞的频率
水线	交换机ECN标记阈值	依缓存而定	触发ECN标记的队列深度

2.4 多租户场景下的水线冲突

在单租户网络中，管理员只需为所有RoCE流量设置一组水线参数。但在多租户数据中心中，多个租户共享同一台物理交换机，每个租户的流量特征差异巨大：

租户A：AI训练任务，流量突发性强，单流带宽需求高，对延迟不敏感但对吞吐要求极高。
租户B：分布式数据库，大量短小报文，对时延极其敏感，但带宽占用低。
租户C：视频转码，持续大流量，但允许一定程度的抖动。

如果交换机对所有租户使用统一水线，必然出现“一刀切”问题：水线调低，租户B的时延得到保障，但租户A的吞吐被频繁降速拖累；水线调高，租户A吞吐上去了，但租户B的时延急剧恶化。更复杂的是，同一租户的流量可能分布在多个队列中，不同队列的深度差异也要求差异化的水线设置。

常见误区：许多运维人员认为“只要把ECN水线调低，就能降低时延”。实际上，水线过低会导致发送端频繁收到CNP，速率振荡剧烈，平均吞吐反而下降。水线调优的目标是找到“吞吐-时延”的帕累托最优点，而非单纯追求某一指标。

2.5 案例：一次水线误配导致的“慢速训练”

某AI集群使用RoCEv2承载分布式TensorFlow训练，网络拓扑为Leaf-Spine架构。训练任务初期吞吐正常，但运行30分钟后整体性能下降至峰值的40%。排查过程如下：

初步检查：网卡无丢包计数，但发送端速率被限制在约10Gbps（物理链路为25Gbps）。
抓包分析：发现接收端持续发送CNP报文，频率约20kHz，说明发送端在频繁降速。
交换机检查：Leaf交换机上RoCE队列深度平均为120KB，而ECN水线被设置为80KB——队列深度持续超过水线，导致所有报文都被标记CE。
根因定位：该交换机同时承载了另一个租户的存储流量，存储流量的突发导致RoCE队列被挤压。管理员此前为降低存储时延，将水线从150KB调低至80KB，未考虑对RoCE训练流量的影响。

最终解决方案是启用交换机的按队列独立水线功能，为不同租户的RoCE队列设置差异化阈值：训练流量队列水线设为150KB，存储流量队列水线设为60KB。调整后训练吞吐恢复至峰值，存储时延也保持在目标范围内。