注：本文仅代表个人观点，与作者任职的机构无关。
TL;DR
最近尝试用漫画的形式来聊聊RDMA现代化，希望让不太了解网络的同学也能看懂。这种讲述方式在某些比喻上可能不够严谨，本文更偏向于科普。更严肃深入的内容可以参考相关专题。
1. 保持松弛感，拥抱有损网络
1.1 为什么需要在以太网上支持RDMA
基于 TCP/IP 的通用以太网是一个“尽力而为”的网络，它保持了很好的“松弛感”，因此可能会存在高峰时期的拥堵造成丢包。但正是因为这份“松弛感”，使得它的建设成本相对低廉。
在某些场合，例如 AI 训练/推理及 HPC 场景需要满足严格的 SLA（服务水平协议），提供可保证的性能。通常采用专用的 Infiniband 网络构建，通过专门的硬件支持来实现高性能网络，为数据传输提供严格的承诺：在网络内部，通过流控机制确保不因拥塞而丢包，端到端延迟极低且稳定无抖动，带宽也能保证。
但是这样的专用网络成本很高，并容易成为一个孤岛。成本原因使得它无法触达很多终端，就像高铁站无法修到每家每户的家门口一样。但是，我们总是希望鱼与熊掌兼得：
如何在低成本的通用以太网上，接受“尽力而为”的特点，保持“松弛感”（接受可丢包的有损网络），又能够达到 AI/HPC 等高性能计算的需求？
1.2 谈谈 RoCE
RoCE（RDMA over Converged Ethernet）便是基于这个目标的一次尝试。它试图在一个尽力而为的以太网上，通过 PFC（Priority Flow Control）和一些拥塞控制算法来提供高性能网络服务，保证不丢包。这就相当于在城市的公共道路系统通过交警和红绿灯控制来防止拥塞，但有时又需要封闭整段道路才能保证高优先级流量通过，这样其它业务就受损了。
特别来说，当更多人都要申请封路保证自己高优先级传输时，整个交通就可能瘫痪。这就是 PFC 经常被诟病的问题。
为了保证 RoCE 能够实现高性能的网络传输，我们需要精心地呵护它，通过细致地调整拥塞控制算法和局部开启 PFC 的方式避免全局死锁。这就好比在城市的公共道路系统中，允许局部的封路和部分路段的限速来优化拥堵情况。
但是，整个解决方案会变得非常复杂，就像在呵护一个“巨婴”。不同的城市路网（网络环境）还需要不同的调整策略。
1.3 现代 AI 网络的问题
传统的 HPC 应用使用的 RDMA 通信特征为小数据量并且延迟敏感，相当于城市道路上都是一些小轿车。通过精细的调整可以很好地运行，并且基本不会出现拥塞丢包的情况。
而 AI 场景下的集合通信通常是突发性很强并且数据量巨大，持续传输时间更长。这就好比大量装载集装箱的卡车突然涌入城市道路，很容易发生碰撞和拥堵。同时，由于整个 AI 通信的同步特性，任何一个慢速传输都会导致整个任务中所有节点等待最慢的那个，这就是所谓的“长尾延迟”问题。
1.3.1 Hash 冲突和负载不均衡
另一方面，网络中通常存在多个路径到达目的地，但交换机通常根据源、目的信息哈希（Hash）的方式选择其中一条路径转发，这容易导致 Hash 冲突。就像在一个有多条公路到达目的地的系统里，大量的集装箱卡车都堵在其中某一条路上，而其它路却空空如也。
1.3.2 跨域长距离传输
随着 AI 集群规模越来越大，单个数据中心已经无法放置数十万颗 GPU，因此出现了跨域（Scale Across）部署。但是，跨域的互连通常受到光纤资源的约束，相当于大量的集装箱卡车全部挤在乡间小路上。同时由于距离较长，拥堵情况需要更长时间才能反馈到发送端，此时拥塞控制算法常常因为调整不及时而导致数据包丢失。
传统的 RoCEv2 采用 Go-Back-N 的机制。例如传输 1, 2, 3, 4, 5 这五个数据包，当 3 发生丢失后，即便接收端已经收到了 4 和 5，它仍然会让发送端从 3 开始重传，即重新发送 3, 4, 5。这种方法使得轻微的丢包（> 0.1%）就会严重影响传输效率。
因此，工程师们通常将其放入更高优先级的队列传输，确保它不丢包。但这又容易导致抢占其它业务流量，引发生产事故。当降级为普通优先级队列后，又需要精细地调整拥塞控制参数来尽力避免丢包。
在这种情况下，传统的 RoCE 像个“巨婴”一样，让照顾它的运维人员非常痛苦。
2. RDMA 现代化
2.1 改善网络中的冲突
为了更好地利用网络带宽，避免因冲突导致的慢速传输和长尾等待，工业界采用了很多办法。例如下左图，通过一个全局的交通管制系统，规划每次通信所使用的路径来避免 Hash 冲突。但是，针对超大规模的集群和多样化的任务，这种全局路径调度器的计算复杂度非常大。
当然，也可以像右图那样，通过更改拓扑结构来尽量避免冲突。例如服务器 A 的 GPU0 需要和服务器 B 的 GPU1 通信。我们可以将数据先从服务器 A 的 GPU0 搬运到同服务器内的 GPU1，然后由 GPU1 发送给服务器 B 的 GPU1。这种情况下，我们只需要在服务器 A 和服务器 B 之间构建“多轨道”网络，即 GPU0 对 GPU0 相连，GPU1 对 GPU1 相连。这样就可以极大改善冲突情况。
多轨道组网虽然通过更改拓扑结构避免了大量冲突，但随着模型结构的变化也引入了新的挑战。例如在 MoE 模型，特别是 Decoding 阶段，对延迟特别敏感，通常希望服务器 A 的 GPU0 能直接发送给服务器 B 的 GPU1，避免中转带来的额外延迟。
因此，业界又探索了一些新的方法，例如 Adaptive Routing（自适应路由） 或 Packet Spray（报文喷洒）。其大致原理是：当数据包到达交换机时，交换机采用轮询等方式动态地将数据包安排到不同的输出链路上。相当于集装箱卡车到达收费站后，收费员通过发号码牌的方式让卡车走不同的车道，从而避免了冲突。
但是，另一个问题出现了：接收方通常需要按照严格的顺序来接收数据。当这些数据包经过不同路径时，耗时可能不同，因此到达时会出现顺序错乱（乱序）的问题。这种做法又引入了新的挑战。
2.2 多路径乱序对丢包检测的影响
传统的 RoCEv2 像一个巨婴，网卡不需要管理复杂的传输状态，仅采用 Go-Back-N 的机制。接收端通过发现序列号不连续来判断丢包，当收到不连续序列号的报文时，就要求发送端从不连续的位置开始重传所有后续报文。
当网络开启 Adaptive Routing 或 Packet Spray 后，数据包经过不同路径到达接收端，很容易产生乱序。然而，Go-Back-N 机制会将这种乱序引起的序列号不连续都武断地判定为丢包，并触发不必要的重传。因此，整个网络可能很快被大量的重传报文淹没。
此外，RoCE 通常需要接收端构建一个用于重新排序的缓存（Buffer）。但这个缓存空间有限，特别是在多个发送端向一个接收端发送大量数据（称为 Incast）的场景下，缓存极易溢出，从而触发丢包，进而又加剧了重传风暴，形成恶性循环。
2.3 DDP（直接数据放置）
聪明的网络工程师们想到了一个巧妙的办法：Direct Data Placement（DDP，直接数据放置）。例如，我们需要运送一个超级大的集装箱（比喻为一个 RDMA 消息）。我们可以把它拆开，把里面的货物分别装载到不同的小汽车上，然后每辆小汽车上都标记这个货物来自哪个大集装箱（即 RDMA 消息号，MSN），以及它是从大集装箱中取出的第几个货物（即偏移量，OFFSET）。最后把这些装在小汽车上的货物通过不同的路径运输。
在接收端，可以根据集装箱的编号（MSN）和货物的编号（OFFSET）直接将货物存入接收方内存的最终位置。当整个集装箱内的所有货物都收齐后，再通知上层应用这个“集装箱”已经处理完毕。
这项技术就是我们常说的乱序接收、有序完成（Out-of-Order Data Delivery, In-Order Completion）。通过这种化整为零的方法，接收端无需准备一个很大的临时缓存区来对数据包进行重排序，极大地节省了资源开销。
这个方法很巧妙吧？但它其实是一个已经存在快二十年的技术了，相关标准早在2002年就已出现。而 RoCE 这个“巨婴”到现在还没有完全支持好。全球范围内能够商用并完整支持所有 RDMA 语义的，目前似乎只有阿里云 CIPU 和 Google 的 Falcon。即便 NVIDIA 也号称在支持 DDP，但据称仍有一些问题没有处理干净。
2.4 SACK（选择性确认）
传统的 RoCEv2 采用 Go-Back-N 机制，这种方法网卡不需要管理复杂的传输状态，但是轻微的丢包（> 0.1%）就会严重影响传输效率。
如果采用 SACK（选择性确认）机制则会成熟得多。例如传输 1, 2, 3, 4, 5 这五个数据包，当 3 丢失后，接收端通过 SACK 消息告知发送端：“请补发 3 号数据包”。发送端仅重传丢失的那个报文即可。即使在 5% 的严重丢包率下，也能满足 90% 以上的有效带宽利用率。当然，其缺点是需要网卡能够进行更智能的数据包状态管理。
3. 告别 RoCE “巨婴”
当我们集齐了多路径转发、DDP 和 SACK 这三颗“龙珠”，就可以告别 RoCE “巨婴”，走向成熟的现代化 RDMA 了。如下图所示：
道理谁都懂，但是做起来却特别困难。对于 DDP 这颗“龙珠”，在阿里云 CIPU eRDMA 设计之初就已支持。我们接下来展开讨论另外两个较难实现的问题。
首先，SACK 虽然高效，但由于需要管理大量复杂的状态和处理各种异常逻辑，如何能够完整实现并保证硬件的低功耗和低成本，是一个巨大挑战。
另一个难题是多路径转发和拥塞控制的协同。当出现拥塞丢包后，系统是先切换路径，还是先进行拥塞控制降低发送速率？这一直是一个两难的决策。这就像在复杂的 分布式系统 中做资源调度，需要精巧的算法来平衡。
3.1 软硬件协同的高效 SACK
阿里云 eRDMA 采用了软硬件协同的设计方式，实现了高效的 SACK 处理，并针对网络中潜在的丢包实现了 RACK-TLP 等重传机制，从而实现了完整的选择性重传和快速重传能力。该技术已经上线稳定运行多年，并在所有地域、所有可用区的多代通用计算实例和大量 GPU 实例上提供支持。
3.2 多路径转发与拥塞控制
CIPU eRDMA 采用了随报文携带时间戳的方式进行带内延迟测量，因此不需要额外的探测包，并且实际数据传输路径和探测路径是完全一致的。在此基础上，我们设计了一套高效的路径负载均衡算法，通过随机动态规划等方法来智能解决拥塞时“换路”还是“降速”的两难问题。
由于 CIPU 可以实现实时监控和微秒级的子流调整，它能够快速、智能地避开拥塞路径。这就像为 网络 数据流提供了一个可靠的“自动驾驶”服务，无需依赖任何特殊的网络配置（如 PFC），就能在高性能模式下稳定工作。这种深度集成正是 云原生 基础设施追求的高效与弹性。
就此，可以召唤“神龙”——一个成熟、高效、能真正拥抱有损通用网络的现代化 RDMA 方案已经实现。
反观那些还停留在协议草案、标准讨论和白皮书阶段的各式“魔改”方案，不禁让人感慨，务实的产品化道路才是技术价值的最终体现。关于网络与高性能计算的更多深度讨论，欢迎在 云栈社区 交流分享。
发表于 昨天 06:40
|
查看: 5|
回复: 0
