将晦涩难懂的技术讲的通俗易懂
分类： LINUX
2025-01-17 23:34:26
Lossy网络的RoCE方案——IRN
这篇文章主要是对《Revisiting Network Support for RDMA》这篇论文的分析，是UC Berkeley和Mellanox在2018 sigcomm会议发表的一篇paper，其核心主要是介绍了RoCE lossy网络的方案，以去除PFC的相关依赖。
RDMA 在高性能计算（HPC）社区中长期以来一直被用于使用基于credit的流量控制的专用 Infiniband 集群，以确保网络无丢包(lossless)。由于在这类集群中数据包丢失很少，因此 RDMA Infiniband 传输（在 NIC 上实现）并未设计为高效地从数据包丢失中恢复。当接收方收到乱序数据包时，它会简单地丢弃该数据包并向发送方发送负确认（NACK）。当发送方看到 NACK 时，它会重新传输所有在{BANNED}最佳后一个被确认数据包之后发送的包（即，go-back-N）。为了利用以太网在数据中心的广泛使用，RoCE 被引入以实现 RDMA 在以太网上的应用。RoCE 采用了相同的 Infiniband 传输设计（包括回退 N 丢包恢复），并通过 PFC 实现了网络无丢包。
优先级流量控制（PFC） 是以太网的流量控制机制，其中交换机会在队列超过某个配置阈值时向上游实体（一个交换机或 NIC）发送暂停（或 X-OFF）帧。当队列降低到该阈值以下时，会发送 X-ON 帧以恢复传输。当配置正确时，PFC 使网络无丢包（只要所有网络元素保持正常工作）。然而，这种对拥堵的粗略反应对导致拥堵的流量是无差别的，这导致了近年来在多篇论文中记录的各种性能问题 ，例如队头阻塞、拥塞传播和偶发的死锁等。
因此本篇论文提出了一种适用于lossy的方案，称为IRN (Improved RoCE NIC)，该设计对当前 RoCE NIC 进行了两个增量改进：(i) 更有效的丢包恢复，以及 (ii) 基本的端到端流量控制，以限制传输中的数据包数量。
IRN对当前的RoCE NIC进行两项关键更改，如以下小节所述：(1) 改进丢包恢复机制，(2) 基于带宽延迟乘积的基本端到端流量控制（称为BDP-FC），该机制限制了在传输中的数据包数量。并且这些更改与使用显式拥塞控制机制（如DCQCN 和Timely）是正交的，后者就像当前的RoCE NIC一样，可以在IRN中选择性启用。
● IRN的丢包恢复机制(选择重传)
如前所述，目前的RoCE NIC使用的是go-back-N丢包恢复方案。在没有PFC的情况下，go-back-N丢包恢复引发的冗余重传会导致显著的性能损失。因此，我们对IRN的{BANNED}中国第一个改动是采用更高效的丢包恢复机制，基于选择性重传（受TCP丢包恢复的启发），接收方不会丢弃乱序包，发送方则选择性地重传丢失的数据包，具体如下。
每当接收到一个乱序包时，IRN接收器会发送一个NACK，该NACK携带了累积确认（指示其期望的序列号）和触发NACK的数据包的序列号（作为选择性确认或SACK的简化形式）。IRN发送方在接收到NACK或发生超时时进入丢包恢复模式。它还维护一个位图，以跟踪哪些数据包已被累积和选择性确认。当处于丢包恢复模式时，发送方根据位图选择性重传丢失的数据包，而不是发送新的数据包。进入丢包恢复模式时重传的{BANNED}中国第一个数据包对应于累积确认值。只有在有更高序列号的数据包被选择性确认后(收到了乱序的ACK)，后续的数据包才被视为丢失。当没有更多需要重传的丢失数据包时，发送方继续发送新数据包（如果BDP-FC允许的话）。当收到大于恢复序列的累积确认时，它退出丢包恢复，恢复序列对应于在重传丢失数据包之前发送的{BANNED}最佳后一个常规数据包。
只有当在传输中有多个数据包时，SACK才能实现有效的丢包恢复。对于其他情况（例如，单数据包消息），丢包恢复则通过超时触发（缺少类似TCP的TLP机制）。较高的超时值可能会增加此类短消息的尾延迟。然而，保持超时值过小可能会导致过多的虚假重传，从而影响整体结果。因此，IRN发送方在传输中的数据包数量较小的情况下（即虚假重传保持在可忽略的小范围内）使用较低的超时值RTOlow，而在其他情况下使用较高的超时值RTOhigh。
● IRN的BDP-FC机制
对IRN进行的第二项改进是引入了一种基本的端到端报文级流量控制机制，称为BDP-FC，该机制通过网络的带宽-延迟积（BDP）来限制流中在飞行中的未确认报文数量。这是一个静态上限，我们通过将网络中{BANNED}最佳长路径的BDP（以字节为单位）除以RDMA队列对设定的报文{BANNED}最佳大传输单元（MTU，通常在RoCE网络接口卡中为1KB）来计算。只有当在飞行中的报文数量（计算方式为当前报文的序列号与{BANNED}最佳后确认序列号之间的差值）少于此BDP上限时，IRN发送器才会发送新报文。
BDP-FC通过减少网络中的不必要排队来提高性能。此外，通过严格限制乱序报文到达的数量，它显著减少了在网络接口卡（NIC）中追踪报文丢失所需的状态量。
接下来，我们研究启用PFC对IRN和RoCE性能的影响。通过测试得出以下结论：
1. IRN不需要PFC，并且如图2PFC还会显著降低IRN的性能（每个指标的值增加约1.5-2倍），这主要是由于PFC所导致的头部阻塞和拥塞传播问题：一个链路上因拥塞引发的暂停，会导致其他上游设备的排队积压和暂停，从而形成级联效应。
2. RoCE 需要 PFC，图 3 显示了在有 PFC 和没有 PFC 的情况下 RoCE 的性能。我们发现，使用 PFC 在这里有很大的帮助。在三种指标上，禁用 PFC 导致性能下降 1.5-3 倍。这是因为当前 RoCE NIC 使用的 Go-Back-N 丢包恢复机制，由于 (i) 重传造成的增加拥塞以及 (ii) 流程在发送这些冗余数据包时浪费的时间和带宽，损害了性能。
3. 明确了拥塞控制的影响。之前的比较没有使用任何明确的拥塞控制。然而，如前所述，RoCE 通常与某些明确拥塞控制机制（如 Timely 或 DCQCN）结合部署。我们现在评估使用这些明确的拥塞控制机制是否会影响上面描述的关键趋势。图 4 比较了在使用 Timely 或 DCQCN 时 IRN 和 RoCE 的性能。IRN 在三项指标上继续以 1.5-2.2 倍的优势表现得更好。图 5 评估在使用 Timely 或 DCQCN 时启用 PFC 对 IRN 的影响。我们发现，IRN 的性能几乎不受 PFC 的影响，因为明确的拥塞控制降低了数据包丢失率和生成的暂停帧数量。启用 PFC 带来的{BANNED}最佳大性能提升不足 1%，而其{BANNED}最佳大负面影响约为 3.4%。{BANNED}最佳后，图 6 在使用 Timely 或 DCQCN 时比较了 RoCE 在有 PFC 和没有 PFC 时的性能。我们发现，与 IRN 不同的是，RoCE（其低效的 Go-Back-N 丢包恢复）即使在使用明确的拥塞控制时，也需要 PFC。启用 PFC 使 RoCE 的性能在三项指标上提高了 1.35 到 3.5 倍。关键结论：因此，以下是这些结果的三个关键要点：（1）IRN（没有 PFC）的表现优于 RoCE（有 PFC）；（2）IRN 不需要 PFC；（3）RoCE 需要 PFC。
我们现在对IRN进行因子分析，以单独研究IRN所做的两个关键变化的重要性，即：（1）高效的损失恢复；（2）BDP-FC。为此，我们将IRN的性能与两种不同的变体进行比较，以突出每一变化的重要性：（1）启用go-back-N损失恢复，而不是使用SACKs；（2）禁用BDP-FC。图7展示了结果的平均完成时间（FCT），我们在其他指标上看到了类似的趋势。下面我们将更详细地讨论这些结果。
高效损失恢复的必要性：图7中的前两个柱状图分别比较了基于SACK的默认IRN和使用go-back-N的IRN的平均FCT。我们发现，后者的性能显著较差。这是因为go-back-N由于冗余重传而浪费了带宽，正如之前所描述的。特别地，我们探讨了以下几个问题：
（1）go-back-N能否更高效？go-back-N在简单性上确实比选择性重传更具优势，因为它允许接收方简单地丢弃乱序的分组。因此，我们试图探索是否可以减轻go-back-N的负面影响。我们发现，在丢包发生时减缓重传提高了go-back-N在Timely下的性能（但对DCQCN没有改善）。尽管如此，基于SACK的损失恢复在不同场景下仍表现得显著更好（在Timely下，平均FCT的差异范围为20%至50%）。
（2）我们需要SACKs吗？我们尝试了一种不使用SACK的选择性重传方案（即发送方不维护位图来跟踪选择性确认）。这种方案比go-back-N表现得更好。然而，当窗口中出现多个损失时，它表现较差，需要多个往返来恢复。与基于SACK的IRN相比，平均FCT相应降级在不同场景下的范围从不到1%到75%不等。
（3）超时值能否动态计算？正如前文所述，IRN使用两个静态（低和高）超时值，以允许短消息更快恢复，并避免大消息的虚假重传。我们还实验了一种使用动态计算的超时值（类似于TCP）的替代方法，这不仅使设计复杂化，而且由于这些效应{BANNED}最佳终被初始超时值所主导，因此并没有带来帮助。
我们现在讨论如何逐步更新RoCE NIC，以支持IRN的传输逻辑，同时保持符合Infiniband RDMA规范定义的RDMA语义的正确性。我们的实现依赖于对RDMA数据包格式的扩展，例如引入新的字段和数据包类型。这些扩展被封装在IP和UDP头中（如RoCEv2所示），因此它们只影响终端主机的行为，而不影响网络行为（即在交换机上不需要任何更改）。在描述IRN如何支持这些操作之前，我们将提供一些关于不同RDMA操作的相关背景。
与 RDMA 消息传输相关的两个远程端点称为请求者和响应者。用户应用与 RDMA NIC 之间的接口由工作队列元素（Work Queue Elements，简称 WQEs，发音为“wookies”）提供。应用程序为每个 RDMA 消息传输发布一个 WQE，该 WQE 包含应用程序指定的传输元数据。在消息处理期间，该 WQE 被存储在 NIC 中，并在消息完成时过期。在请求者和响应者 NIC 上发布的 WQEs 分别称为请求 WQE 和接收 WQE。WQE 在消息完成时过期后，会创建一个完成队列元素（Completion Queue Element，简称 CQE，发音为“cookie”），该元素向用户应用程序发出消息完成的信号。RDMA NIC 支持四种类型的消息传输：
● 写入（Write）：请求者将数据写入响应者的内存。数据长度、源和接收位置在 Request WQE 中指定，通常不需要 Receive WQE。不过，带立即操作的写入（Write-with-immediate）需要用户应用程序发布一个在完成时过期的 Receive WQE 以生成 CQE（从而也向响应者信号写入完成）。
● 读取（Read）：请求者从响应者的内存中读取数据。数据长度、源和接收位置在 Request WQE 中指定，且不需要 Receive WQE。
● 发送（Send）：请求者将数据发送给响应者。数据长度和源位置在 Request WQE 中指定，而接收位置在 Receive WQE 中指定。
● 原子操作（Atomic）：请求者读取并原子性地更新响应者内存中的一个位置的数据，该位置在 Request WQE 中指定。无需 Receive WQE。原子操作仅限于单包消息。
IRN 依赖于每包 ACK 进行 BDP-FC 和丢包恢复。RoCE NIC 已经支持写入和发送的每包 ACK。然而，在进行读取时，请求者（数据接收者）并不显式确认读取响应数据包。因此，IRN 引入了为每个读取响应数据包由请求者发送的读取（N）ACK 数据包。RoCE 当前有八个可用于可靠连接 QPs 的未使用操作码值，我们使用其中一个用于读取（N）ACK。IRN 还要求读取响应者（数据源）实现超时。过去 NIC 硬件实现中已经添加了新的定时器驱动操作 。因此，这不是一个问题。RDMA 原子操作被视为类似于单包 RDMA 读取消息。
实现 IRN 的一个关键挑战是支持接收端的乱序（OOO）数据包传递——目前的 RoCE NIC 会直接丢弃 OOO 数据包。处理 OOO 数据包的一种简单方法是将所有数据包存储在 NIC 内存中。使用 IRN 时，OOO 数据包的总数受到 BDP 上限的限制（在我们在前文中描述的默认场景下，大约为 110 个 MTU 大小的数据包）。因此，为了支持千条流，一个 NIC 需要缓冲 110MB 的数据包，这超过了大多数商品 RDMA NIC 的内存容量。
因此，我们探索了一种替代的实现策略，其中 NIC 将 OOO 数据包直接 DMA（直接内存存取）到应用程序内存中的{BANNED}最佳终地址，并使用位图（大小为 BDP 上限）跟踪它们。这将 NIC 的内存需求从每个 OOO 数据包的 1KB 降低到仅仅几个比特，但也带来了一些额外的挑战，我们将在此进行讨论。需要注意的是，部分支持 OOO 数据包传递的功能已经在 Mellanox ConnectX-5 NIC 中引入，以启用自适应路由（AR）。然而，该功能仅限于写和读操作。我们改进并扩展了该设计，以支持所有 RDMA 操作与 IRN。我们将由于乱序数据包传递造成的问题分为四类。
1. {BANNED}中国第一个数据包的问题。对于某些 RDMA 操作，关键信息在消息的{BANNED}中国第一个数据包中，这对于处理消息中的其他数据包是必需的。因此，启用 OOO 传递要求所有数据包都携带{BANNED}中国第一个数据包中的一些信息。特别是，RETH 头（包含远程内存位置）仅由写消息的{BANNED}中国第一个数据包携带。IRN 需要将其添加到每个数据包中。
2. WQE 匹配问题。有些操作要求每个到达的数据包都要与响应方的相应 WQE 进行匹配。这在顺序到达的情况下是隐式完成的。然而，当数据包无序到达时，这种隐式匹配就会失效。为了解决这个问题，可以为 WQE 分配显式的序列号，这些序列号会被携带在数据包头中，可以用于识别每个数据包对应的 WQE。IRN 在以下 RDMA 操作中使用了这一解决方法：
○ Send and Write-with-immediate：要求接收 WQE 被发送和带立即数写请求以其发布顺序消耗。因此，在 IRN 中，每个接收 WQE，以及这些操作的每个请求 WQE，都会维护一个 recv_WQE_SN，用于指示它们的发布顺序。这个值在所有发送数据包和{BANNED}最佳后一个带立即数的写数据包中携带，并用于识别适当的接收 WQE。IRN 还要求发送数据包携带数据包序列号中的相对偏移，用于在放置数据时确定精确地址。
○ Read/Atomic：响应方在接收到所有预期在读取/原子请求 R 之前到达的数据包后，才能开始处理读取/原子请求 R。因此，OOO 读取/原子请求数据包需要在响应方的读取 WQE 缓冲区中放置（当前的 RoCE NIC 已经在维护这个缓冲区）。在 IRN 中，每个读取/原子请求 WQE 维护一个 read_WQE_SN，这个序列号被所有读取/原子请求数据包携带，并允许识别在该读取 WQE 缓冲区中的正确索引。 （BF3未实现）
3. {BANNED}最佳后一个数据包问题。对于许多 RDMA 操作，关键的信息包含在{BANNED}最佳后一个数据包中，这对于完成消息处理是必需的。因此，启用无序交付要求跟踪这样的{BANNED}最佳后一个数据包到达，并在端点（NIC 或主内存）中存储这一信息，直到该消息的所有其他数据包都到达。我们将在下面详细解释这一点。
○ RoCE 响应方维护一个消息序列号（MSN），当接收到写/发送消息的{BANNED}最佳后一个数据包或接收到读取/原子请求时，该序列号会递增。这个 MSN 值会在 ACK 数据包中发送回请求者，并用于失效相应的请求 WQE。当接收到Send或Write-With-Immediate消息的{BANNED}最佳后一个数据包时，响应方也会使其接收 WQE 失效，并生成 CQE。CQE 会填充与传输相关的某些元数据，这些元数据由{BANNED}最佳后一个数据包携带。因此，IRN 需要确保完成信号机制能够正确工作，即使消息的{BANNED}最佳后一个数据包在其他数据包之前到达。
○ 为此，IRN 响应方维护一个 2-bit 映射，除了跟踪数据包 p 是否到达外，还跟踪它是否为消息的{BANNED}最佳后一个数据包，并将触发 (1) MSN 更新和 (2) 在某些情况下，Receive WQE 失效，随后生成 CQE。这些操作仅在接收到所有到达 p 之前的数据包后才会触发。对于第二种情况，由 p 携带的 recv_WQE_SN（如前所述）可以识别需要与 p 中元数据相关联的接收 WQE，从而启用过早的 CQE 创建。这个过早的 CQE 可以存储在主内存中，直到在 p 之前的所有数据包都到达后将其传递给应用程序。
4. 应用层问题。一些应用（例如 FaRM ）依赖轮询写消息的{BANNED}最佳后一个数据包来检测完成，这与异步数据放置（OOO data placement）不兼容。这种基于轮询的方法违反了 RDMA 规范（Sec o9-20 [4]），并且比官方支持的方法更昂贵（FaRM 提到未来将转向使用官方支持的即时写（Write-with-Immediate）方法以实现更好的可扩展性）。IRN 的设计提供了按照 RDMA 规范的所有写完成保证。
OOO 数据放置还可能导致一种情况，即写入特定内存位置的数据被来自旧消息的重传数据包覆盖。通常，使用分布式内存框架的应用假设放松内存排序(relaxed memory ordering)，并在需要强内存一致性时使用应用层fences。因此，支持 OOO 数据放置的 iWARP 和 Mellanox ConnectX-5 期待应用程序处理潜在的内存覆盖问题，而不在网络接口卡（NIC）或驱动程序中处理此问题。IRN 可以采用相同的策略。另一种替代方案是在驱动程序中处理这个问题，通过为可能覆盖旧请求的新发布请求启用fences指示器。
目前，请求者发送和接收的数据包使用相同的数据包序列号（PSN）空间。这干扰了丢包跟踪和带宽延迟产品-流控制（BDP-FC）。因此，IRN 将 PSN 空间分成两个不同的空间：（1）sPSN 用于跟踪请求者发送的请求数据包，以及（2）rPSN 用于跟踪请求者接收的响应数据包。这种解耦对应用程序透明，并且与当前的 RoCE 数据包格式兼容。IRN 还可以支持共享接收队列和带失效操作的发送，并且与端到端credit的使用兼容。
同时，本篇论文也对iWARP进行了一些讨论和对比，我们先看一下论文中对iWARP的评价：
iWARP 的设计旨在支持在一个完全通用（即，不是lossless）网络上进行RDMA。iWARP在硬件中实现了完整的TCP协议栈，以及多个需要将TCP的字节流语义转换为RDMA段的其他层。在我们工作的早期阶段，我们与多家网络接口卡（NIC）供应商和数据中心运营商进行了接触，以试图理解为何iWARP没有得到更广泛的采用（因为我们认为iWARP的基本架构前提是正确的）。我们听到的一致反馈是，iWARP的复杂性和成本显著高于RoCE，并且性能劣于RoCE 。
我们还寻找实证数据来验证或反驳这些说法。我们在两台相互连接的机器上进行了RDMA写入基准测试，在一组实验中使用了两台机器上的Chelsio T-580-CR 40Gbps iWARP NIC，而在另一组实验中则使用了Mellanox MCX416A-BCAT 56Gbps RoCE NIC（链路速度设定为40Gbps）。这两种NIC的规格相似，在购买时，iWARP NIC的价格为760美元，而RoCE NIC的价格为420美元。我们发现iWARP的延迟是RoCE的3倍，吞吐量则低于RoCE 4倍。这些价格和性能差异可能归因于运输设计复杂性以外的许多因素（例如，利润率差异、支持的特性和工程投入），因此应被视为佐证证据。然而，它们显示了我们支持在终端主机NIC实现丢包恢复的假设，并不明显，基于当前的iWARP NIC。
我们的主要贡献是表明，iWARP，令人惊讶地，实际上拥有正确的哲学：在NIC中显式处理数据包丢失导致的性能优于拥有一个无丢包的网络。然而，有效处理数据包丢失并不需要像iWARP那样在硬件中实现整个TCP协议栈。相反，我们识别出对当前RoCE NIC进行的增量更改，从而得出一个设计，该设计（i）不需要优先流量控制（PFC），但能实现优于RoCE和iWARP的网络整体性能，以及（ii）在NIC性能和复杂性方面与RoCE的实现更为接近，因此比iWARP显著简单。
总结来说，论文作者认为iWARP的设计理念是正确的，但是采用TCP协议栈卸载，以及基于TCP字节流的处理给硬件带来了较大复杂性，并且影响性能和成本。例如在选择重传场景中，论文提到IRN的丢失恢复灵感来源于TCP的丢失恢复。然而，IRN的选择重传与iWARP网络接口卡将整个TCP栈纳入不一样，具体有以下两方面：
（1）将丢失恢复与拥塞控制解耦，不涉及TCP拥塞窗口控制中的慢启动、加性增量乘法减量（AIMD）或高级快速恢复的任何概念，
（2）直接对RDMA段进行操作，而不是使用TCP的字节流抽象，这不仅避免了iWARP所需的多个转换层引入的复杂性，而且还允许IRN简化其选择性确认和丢失跟踪机制。
但天下没有免费的午餐，一方面，简单必然带来功能的缺失，核心还是看功能的重要性和实现的代价，例如IRN的选择重传就无法支持常规乱序场景，例如多路径情况带来的out of order问题，也不好处理尾包丢失问题。有关这些问题的解决方案，我们在之前讲RACK文章中有分析；另一方，其实NVIDIA的网卡也在继续去借鉴TCP补齐一些短板。所以本质是TCP做减法，还是UDP做加法的问题，殊途同归，关键还是看需要什么特性，以及付出的代价是否值得。
