什么是RoCE？

RDMA（远程直接内存访问）作为一种编程模型，允许应用程序绕过内核直接读写远端内存，大幅降低CPU开销。当这种能力被移植到标准以太网环境中时，就诞生了RoCE（RDMA over Converged Ethernet，即融合以太网上的RDMA）。简单来说，RoCE保留了RDMA的语义和操作接口（如verbs API），只是将底层传输介质从专用的InfiniBand网络换成了以太网。

RoCE有两个主要版本：

• RoCEv1：工作在单一的Layer 2广播域内，无法跨子网路由。
• RoCEv2：将RDMA流量封装在UDP/IP中，支持Layer 3网络路由，成为绝大多数实际部署的标准选择。

虽然编程模型没有改变，但网络行为发生了根本变化。以太网默认不保证无损传输，因此RoCE必须依赖额外的拥塞控制和丢包避免机制，这使得性能的稳定性从应用程序转移到了网络基础设施的配置上。

RoCE的应用场景

当企业已经拥有成熟的以太网基础设施，且不愿更换为独立的InfiniBand网络时，RoCE就成为了最佳折衷方案。它允许在现有网络上增量引入RDMA能力，无需改变网络的管理模式或操作经验。

常见部署环境包括：

• 分布式存储系统
• 数据库集群
• 加速器驱动的工作负载（如GPU训练）

这些场景中，复用现有网络与追求性能同样重要。RoCE本质上是一种实用主义的权衡：在避免全面重写网络栈的前提下，突破应用程序的性能瓶颈。

以太网 vs. InfiniBand：行为差异

要理解RoCE在实际中的表现，必须对比两个不同的世界：InfiniBand原生支持RDMA，而以太网需要做出调整。

• InfiniBand：自底向上设计了无损传输，流控和拥塞管理集成在传输层，负载下延迟稳定。
• 以太网：默认允许丢包，由上层协议（如TCP）负责恢复。这种设计源于早期以太网的共享介质特性，强调简单性和成本，将复杂性推到协议栈上层。

传统以太网的高层协议（如TCP）可以容忍丢包，因为重传机制是内置的。但RDMA完全不同——它要求网络行为可预测、零丢包，因为任何重传都会破坏延迟保证并打乱细粒度的通信模式。RoCE因此必须在一开始就非无损的以太网之上“强行”附加一套丢包避免机制。

为什么RDMA会“压垮”以太网？

RDMA工作负载具有高度同步和突发性的特点。例如分布式训练中的集合通信操作，多个节点同时向同一接收端发送数据，造成“incast（多对一收敛）”流量。此时交换机缓冲区迅速耗尽，传统以太网就会发生丢包。

• PFC（优先级流控）：通过暂停入口端口的流量来避免队列溢出。但其按优先级进行全局暂停，可能导致不相关的流量也被阻塞，引发“头部阻塞（HoL blocking）”问题。
• ECMP（等价多路径）：依赖哈希分发流量，但同步的AI/HPC流量往往不会均匀分布，导致部分链路拥塞而其他链路空闲。

为了解决这些问题，业界引入了多种机制：

• ECN（显式拥塞通知）：在队列溢出前标记数据包，让端设备主动降速。
• DCB（数据中心桥接）：定义流量类别隔离与优先级。
• DCQCN（数据中心量化拥塞通知）：结合ECN信号动态调节发送速率。

因此，RoCE的性能高度取决于以太网络的工程调优。一个精心调校的RoCE网络可以在延迟和吞吐量上接近InfiniBand，而调校不佳的网络则会在负载下变得不可预测。队列阈值、ECN标记点、PFC优先级、MTU以及网卡参数之间相互影响，生产环境部署通常需要经过反复的迭代调优。

RoCE能否与普通IP流量共享同一网络？

理论上可以，但实践中需要精心设计。由于RoCE对丢包极为敏感，而普通IP流量（如TCP）可能产生突发性丢包，两者共存时需要通过DCB等机制严格隔离优先级队列。否则，一条普通的TCP流就可能引发PFC风暴，从而拖垮整个RoCE通信。

---

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://ubuntu.com//blog/what-is-rdma-over-converged-ethernet-roce

---

请支持IMCN发展！

谁在捐赠

微信捐赠	支付宝捐赠

扫码关注公众号：智享开源