当前位置：首页 > NSDI > 正文

【NSDI 2022】Justitia：硬件内核旁路网络中的软件多租户

NSDI
2022-10-07
1737
更新：2023-01-04 21:41:12

# 摘要
内核旁路网络（KBN）正在成为现代数据中心的新规范。虽然基于硬件的KBN将所有数据平面任务卸载到专用NIC，以实现比基于软件的KBN更好的延迟和CPU效率，但它也剥夺了运营者对网络共享策略的控制。在多租户硬件KBN中提供策略支持带来了独特的挑战——即保持超低延迟和低CPU成本、找到定义良好的中介点以及重新思考流量整形器。提出的Justitia介绍了三个关键设计方面来解决这些挑战：（i）使用消息级整形的连接分割，（ii）基于发送方的资源调解以及接收方更新，以及（iii）被动延迟监控。Justitia以延迟目标为旋钮，支持多租户策略，如可预测的延迟和公平/加权资源共享。我们的评估表明，Justitia可以以略微降低的利用率为代价有效隔离延迟敏感的应用程序，并确保其余应用程序的吞吐量和带宽不会受到不公平的惩罚。

# 1 导言
为了应对大型扇出服务对超低延迟、高吞吐量（消息速率）和高带宽的日益增长的需求，从内存缓存中的并行查找和资源分解到分析和机器学习，内核旁路网络（KBN）正在成为现代数据中心的新规范。顾名思义，使用KBN，应用程序绕过操作系统（OS）内核以提高性能，同时释放CPU。

当今KBN有两大趋势。基于软件的KBN（例如DPDK）将内核从数据路径中移除，并在用户空间中执行数据包处理。相反，基于硬件的KBN（如RDMA）通过将数据平面任务卸载到具有板载计算功能的专用NIC（如RDMANIC），进一步将延迟降低至少一个数量级，并减少CPU使用。

然而，硬件KBN剥夺了运营者对网络共享策略（如优先级、隔离和性能保证）的控制权。与软件KBN不同，共存的应用程序必须依靠专用NIC在数据传输操作发布到硬件后进行仲裁。我们观察到，现有的硬件KBN对多租户的支持较差。例如，即使对于DARE、eRPC和FaSST等真实应用程序，共享同一NIC也会导致严重的性能异常，包括不可预测的延迟、吞吐量受限（即较低的消息速率）和不公平的带宽共享（第3节）。在本文中，我们旨在解决以下问题：我们能否将软件KBN网络的优势与硬件KBN网络效率结合起来，实现细粒度多租户支持？

最近的工作探索了大规模基于软件的KBN部署中的多租户支持。他们的设计在终端主机上实施细粒度共享策略，如性能和安全（地址空间）隔离，并在网络结构成为瓶颈时与结构级解决方案（如拥塞控制）结合（图1）。然而，由于三个独特的挑战，现有的软件KBN解决方案无法应用于基于硬件的KBN：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">由于不再涉及主机CPU，因此无法应用基于CPU的通用资源分配机制。相反，租户以无CPU成本的方式发布具有任意数据负载的RDMA操作，这使得没有明显的控制点来进行资源中介。
</span>

我们提出了Justitia，这是一种纯软件解决方案，能够在基于硬件的KBN中支持多租户，以应对上述挑战（第4节）。我们的主要想法是在NIC前面引入一个高效的软件仲裁器，该仲裁器可以实现与性能相关的多租户策略，包括（1）公平/加权资源共享和（2）可预测的延迟，同时最大化利用率或两者的混合。鉴于RDMA是当今主要的基于硬件的KBN实现，在本文中，我们特别关注RDMA NIC（RNIC）上的解决方案。

在RDMA中启用细粒度共享策略需要一种有效的RNIC资源管理方法（即链路带宽和执行吞吐量）。为此，我们提出了连接分割，将租户应用程序的意图与其驱动解耦，并引入资源点中介。Justitia通过结合基于发送方和基于接收方的设计的优点来调解RNIC资源。在将RDMA操作放置到RNIC上之前，在发送方对其进行分割和整形；收集接收端更新以避免因incast或RDMA读取争用引起的虚假资源分配。整形是在消息级别执行的，其中消息大小及其速度根据当前使用的策略动态调整。通过拆分RDMA连接，Justitia可以根据我们设置的策略有效管理租户的连接以消耗RNIC资源，而不是让租户自己通过任意发布RDMA操作来竞争。

为了为延迟敏感的应用程序提供可预测的延迟，Justitia引入了参考流的概念，并监控其延迟，而不是拦截低延迟租户应用程序。通过比较从同一发送方机器到不同接收方的许多参考流的延迟测量，Justitia可以快速检测（本地和远程）RNIC资源争用。给定尾部延迟目标，Justitia在不违反目标的情况下最大化RNIC资源利用率。当目标无法实现时，基于运营者定义的策略，Justitia可以选择确保竞争的n个实体中的每一个获得RNIC两个资源中的至少1/n，从而将网络共享的经典软管模型/hose model扩展到多资源RNIC。

我们已经在InfiniBand和RoCEv2网络上实施了（第5节）并评估了（第6节）Justitia。它在不同类型的应用程序之间提供多租户支持，而不会导致高CPU使用率（每台主机1个CPU核）、额外开销或修改应用程序代码。例如，使用Justitia，当与带宽敏感的存储应用程序Apache Crail并行运行时，DARE的尾部延迟提高了3.4倍，Justitia保留了Crail原始性能的81%。Justitia还补充了RDMA拥塞控制协议，如DCQCN，同时进一步缓解了接收方RNIC争用，并减少了尾部延迟，即使在网络拥塞时也是如此。

# 2、背景

最近的工作发现了由于端侧主机资源争用而导致的不可预测的延迟，但他们的主要关注点是基于软件的KBN中的接收端引擎拥塞。在这项工作中，我们旨在强调，当多个租户共存时，基于硬件的KBN（如RDMA）中的发送方资源争用也会导致严重的性能下降。理想的解决方案应该同时解决发送方和接收方的问题。在本节中，我们将概述如何执行RDMA操作，然后介绍RDMA缺乏多租户支持的根本原因。

## 2.1 RDMA操作的生命周期

RDMA支持用户注册内存区域之间的直接访问，而不涉及操作系统内核，从而将数据传输任务卸载到RNIC。应用程序通过通过队列对（QP）发布工作请求（WR）来启动RDMA操作，以描述要传输的消息。图2显示了RDMA应用程序如何与RNIC交互以启动RDMA操作。为了开始RDMA写入，S1用户应用程序将描述消息的工作队列元素（WQE）放入发送队列（SQ），S2按门铃，通过将其QP号写入RNIC上相应的门铃寄存器来通知RNIC。此时，用户应用程序已完成其任务，并将其余工作卸载到RNIC。RNIC收到通知后，S3它从发送队列中提取并处理请求，S4从用户内存中提取消息，将其拆分为数据包，并将其发送到远程RNIC。最后，远程 RNIC S5将接收到的消息直接写入远程存储器。

在RDMA读取操作的情况下，用户应用程序再次发布WQE并通知RNIC收集它（S1-->S3）。然后，本地RNIC S4’通知远程RNIC从远程存储器中提取数据，S5’在对接收到的数据包进行去分组后将消息放回本地存储器。尽管数据传输方向相反，但远程操作系统仍然是被动的，就像RDMA写入一样。在这两种情况下，RDMA操作的发送方主动控制进入RNIC的内容，而远程侧保持被动不知道。

## 2.2 缺乏多租户支持

RDMA缺乏多租户支持主要有两个原因：（i）租户/应用程序竞争多个RNIC资源，以及（ii）RNIC进程准备以贪婪的方式消耗消息以最大化利用率。两者都与隔离问题的不同症状有关。

**多资源争用**。存在两种需要在RNIC上共享的主要资源：链路带宽和执行吞吐量。对带宽敏感的应用程序消耗RNIC的链路带宽来发出大型DMA请求。另一方面，吞吐量敏感的应用程序消耗RNIC的执行吞吐量，以批量发出小型DMA请求。然而，对延迟敏感的应用程序既不消耗资源，也不使用它们稀疏发送的小消息。正如我们将很快展示的（第3节），当应用程序竞争不同的资源时，可能会出现隔离异常。

**高利用率的贪婪处理**。虽然实际的RNIC实现细节是私有的，但我们可以考虑两种假设，即RNIC如何同时处理多个请求：图2中S3中收集的来自多个应用程序的RNIC缓冲区WQE，并使用某种调度机制在它们之间进行仲裁；或者它以贪婪的方式处理它们。当延迟敏感应用程序与带宽敏感应用程序竞争时，前者仲裁过多会导致资源利用率低（例如，无法赶上线路速率），而后者仲裁过少则会导致线路前端（HOL）阻塞（从而导致延迟变化）。我们对所有三种RDMA实现（第3节）的观察结果表明，使用小消息的应用程序始终受到使用大消息的应用的影响。请注意，尽管如“Uno: Unifying host and smart nic offload for flexible packet processing”中指出的那样，在步骤S5期间也可能发生接收方拥塞，但这两个根本原因很容易源自操作的发送方通过步骤S3，因此不能忽略。我们在第4节详细说明 Justitia 如何缓解发送方和接收方的问题。

# 3 RDMA中的性能隔离异常

本节确立了对硬件KBN中共享特性的基本理解，并确定了微基准（第3.1节）和高度优化的基于RDMA的应用程序（第3.2节）的不同RDMA实现之间的常见隔离异常。

为了研究具有不同目标的应用程序之间的RDMA共享特性，我们考虑三种主要类型的支持RDMA的应用程序：

主要发现总结：

在本节的其余部分，我们将描述我们的实验设置，并详细阐述这些发现。

## 3.1 微基准的观测结果

我们使用相同类型的RNIC在两台机器之间执行微基准测试，其中两台机器都连接到同一个启用RDMA的交换机。对于大多数实验，我们使用56 Gbps Mellanox ConnectX-3 Pro用于InfiniBand，40 Gbps Melanox ConnectX-4用于RoCEv2，40 Gbs Chelsio T62100用于iWARP；10和100Gbps的设置描述类似。有关我们硬件设置的更多详细信息，请参见附录A的表1。

我们的基准测试应用程序是基于Mellanox perftest编写的，每个应用程序都使用一个队列对。除非另有规定，我们的微基准中对延迟敏感的应用程序发送连续的16B消息流，对吞吐量敏感的应用软件发送连续的批次流，每个批次有64条16B消息，对带宽敏感的应用文件发送连续的1MB消息流。尽管在下面的观察中，所有应用程序都使用RDMA通过可靠连接（RC）QP发送消息，但其他verb也显示出类似的异常。我们将硬件虚拟通道的使用和讨论推迟到第6.3节。

### 3.1.1 对延迟和吞吐量敏感的应用程序都需要隔离

对于所有RDMA实现，延迟敏感应用程序的性能都会下降（图3）。在我们进行基准测试的三种实现中，InfiniBand和RoCEv2观察到中位延迟分别下降1.85倍和3.82倍，第99百分位分别下降2.23倍和4倍。虽然iWARP在中值延迟方面表现良好，但其尾部延迟显著下降（95×）。

吞吐量敏感的应用程序也会受到影响。当后台带宽敏感应用程序运行时，吞吐量敏感应用程序在所有RDMA实现中观察到吞吐量下降2.85×或更多（图4）。请注意，在每个应用程序具有1个QP的微基准中，消耗NIC执行吞吐量的吞吐量敏感应用程序遇到瓶颈。这并不意味着RNIC总是倾向于链路带宽而不是执行吞吐量。我们注意到，当存在4倍以上的吞吐量敏感应用时，RNIC带宽开始成为瓶颈。

更重要的是，随着对带宽更敏感的应用加入竞争，对延迟和吞吐量敏感的应用程序都会经历更严重的性能下降（例如，16个带宽应用程序的延迟下降了139X），这在共享数据中心中非常普遍。附录B.1提供了更多细节。

### 3.1.2 对延迟敏感的应用程序共存良好；吞吐量敏感型也是如此

我们没有观察到延迟或吞吐量敏感的应用程序之间的明显异常，或者这两种类型的混合。详细结果见附录B。

### 3.1.3 带宽敏感应用互相伤害

与延迟和吞吐量敏感的应用程序不同，消息大小不同的带宽敏感应用程序会相互影响。图5显示，使用1MB消息的带宽敏感应用程序接收的共享比使用1GB消息的应用程序小。后者在InfiniBand、RoCEv2和iWARP中分别接收1.42倍、1.22倍和1.51倍的带宽。

### 3.1.4 更快的网络中也存在异常

我们在100Gbps InfiniBand上执行了相同的基准测试，只是为了观察到大多数上述异常仍然存在。附录C.1提供了详细信息。

## 3.2 真实世界应用程序之间的隔离

在本节中，我们将演示在存在上述异常的情况下，基于RDMA的真实系统如何无法保持其性能。

具体来说，我们使用Apache Crail和DARE进行了实验。Crail是一个利用RDMA的高带宽分布式数据存储系统。相反，DARE是一个对延迟敏感的系统，通过使用基于强一致性RDMA的键值存储提供高性能复制状态机。

在这些实验中，我们将DARE部署在具有64GB内存的InfiniBand上的具有56 Gbps Mellanox ConnectX-3 Pro NIC的4个节点的集群中。Crail部署在同一个集群中，一个节点运行namenode，另一个节点则运行datanode。

为了评估Crail的性能，我们在Crail的数据存储中启动了8次并行写入（每个写入不同的文件），数据传输的块大小配置为1MB，我们测量了Crail报告的应用程序级吞吐量。为了评估DARE的性能，在与Crail的namenode相同的服务器上运行的一个DARE客户端向其他3个节点上的DARE服务器发出PUT和GET操作（每个PUT后面都有一个GET），消息大小从8字节扫描到1024字节，我们测量了DARE报告的应用程序级延迟。

图6绘制了有Crail和没有Crail的情况下DARE查询的延迟。在本实验中，我们观察到DARE的尾部延迟增加了4.6倍。此外，无论Crail是否与DARE竞争，其总写入吞吐量都保持在51.1 Gbps。

除了DARE之外，高度优化的基于RDMA的RPC系统（如FaSST和eRPC）也会因RNIC上的非托管资源争用而出现隔离异常。事实上，当存在大量后台带宽流量时，FaSST的吞吐量下降74%（图32），eRPC的尾部延迟增加40倍（图33）。更多详情见附录C.2。

## 3.3 拥塞控制是不够的

为了证明DCQCN和PFC不足以解决这些异常，我们在NIC和交换机端口启用PFC、NIC启用DCQCN以及Dell 10 Gbps以太网交换机启用ECN标记的情况下再次执行了基准测试（S4048-ON）。在这些实验中，对延迟和吞吐量敏感的应用程序仍然受到不可预测的影响（第6.3节给出了详细结果）。这是因为DCQCN侧重于结构级隔离，而由于RNIC资源争用，观察到的异常发生在终端主机上（第2.2节）。

# 4 Justitia

Justitia在基于硬件的KBN中启用多租户，特别关注启用两个与性能相关的策略：（1） 公平/加权资源共享，或（2）在最大化利用率的同时可预测的延迟，或两者的混合。请注意，在本文中，我们将重点放在协作数据中心环境上，并将战略证明推迟到未来的工作中，以减轻敌对/恶意行为。

控制粒度：我们将流定义为两个RDMA QP之间的RDMA消息流。通过将两个应用程序之间的所有流视为一个整体，可以将Justitia配置为在流粒度或应用程序粒度下工作。在本文中，默认情况下，我们将Justitia的控制粒度设置为应用程序级，以关注应用程序级性能。

## 4.1 关键设计思想

Justitia通过五个关键设计思想解决了在硬件KBN中实现多租户的独特挑战。

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">租户/应用程序级连接管理：为了防止租户通过发布任意大的消息或自由创建大量活动QP占用RNIC资源，Justitia通过在租户应用程序和RNIC之间添加垫片层提供租户级连接管理方案。租户操作在到达RNIC之前由Justitia处理。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">基于发送方的主动资源调解：Justitia主动控制发送方的RNIC资源利用率。这是基于这样的观察：RDMA操作的发送方——决定何时启动操作、消息的大小以及消息的流向——可以主动控制传输的各个方面，而连接的另一端则保持被动。这种基于发送方的控制可以在RNIC接管之前做出反应，并通过直接控制RNIC资源来保持隔离。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">动态接收方更新：当多个发送方共存但彼此不知道时，纯粹基于发送方的方法有时会导致虚假的资源分配。Justitia利用接收方更新向发送方提供信息（例如，应用程序的到达或离开），以便在设置发生变化时做出正确反应。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">带拆分的消息级整形：Justitia在消息级执行整形，以适应RDMA面向消息的传输层。在消息级别，可以很容易地应用特定策略，根据消息的大小和消耗的资源来控制消息如何进入RNIC。大消息被分成大小大致相等的子消息或块，以（i）避免单个消息请求过多的RNIC资源；（ii）促进网络共享政策，如公平/加权带宽共享；以及（iii）减轻延迟敏感应用的HOL阻塞。
</span>

## 4.2 系统概述

图7展示了Justitia处理RDMA写入操作的高级系统概述（与图2进行比较）。每台机器都有一个Justitia守护进程，该守护进程执行延迟监控和主动速率管理，应用程序使用现有API创建QP以执行RDMA通信。Justitia依赖应用程序来选择性地识别其应用程序类型。默认情况下，它们被视为带宽敏感。虚拟机、容器、裸机应用程序和SR-IOV都与Justitia的设计兼容。

与前面一样，用户应用程序通过S1向发送队列中发送WQE来启动RDMA写操作。延迟敏感应用程序将S2a绕过Justitia，直接与RNIC交互，如图2所示。其他两种类型的应用程序将进入Justitie的整形器。拆分器S2b将来自带宽敏感应用程序的大消息平均拆分为子消息，或者S2c在来自吞吐量敏感应用程序小消息的情况下什么都不做。我们引入了连接拆分和相应的拆分队列对（Split-QP）来处理通过拆分器传递的消息。在发送消息之前，S3它要求守护进程从Justitia获取令牌，该令牌以最大化资源饥饿应用程序消耗的RNIC资源利用率的速率生成。一旦取得令牌，S4 Split-QP将子消息的WQE发布到其SQ中，并按门铃通知RNIC。然后RNIC从拆分QP中获取WQE，对应用程序内存区域中的实际数据发出DMA读取，并将消息发送到远程（图中未显示箭头）。重复步骤S3和S4，直到已处理Split QP中的所有消息。拆分QP的实施细节见第5.1节。

图7中的Justitia守护进程是一个后台进程，它执行延迟监控和主动速率管理，以在满足延迟目标时最大限度地提高RNIC资源利用率。

## 4.3 Justitia守护进程

Justitia守护进程执行两项主要任务：（i）使用hose模型主动管理所有带宽和吞吐量敏感的应用程序的速率；（ii）确保延迟敏感应用程序的可预测性能，同时最大限度地提高RNIC资源利用率。

### 4.3.1 最低保证速率

Justitia根据经典软管模型强制执行速率，并始终保持最低保证速率$$R_{min}$$：

$$R_{min} = \frac{\sum w_B^i + Sum w_T^i}{\sum w_B^i + \sum w_T^i+ \sum w_L^i} \times MaxRate$$

其中$$w_X^i$$表示类型X的应用程序i的权重（即，带宽、吞吐量或延迟敏感），$$MaxRate$$表示最大RNIC带宽或最大RNIC吞吐量（两者均基于每个RNIC预先确定），具体取决于应用程序的类型。$$R_{min}$$的思想是识别延迟敏感应用程序的存在，并通过从RNIC资源中取出它们的份额来为它们提供隔离，否则它们无法自己获取。在没有延迟敏感应用的情况下（即，$$\sum w_L^i$$），$$R_{min}$$相当于MaxRate，所有需要资源的应用程序共享整个RNIC资源。如果所有应用程序的权重相等，并且存在B带宽、T吞吐量和L延迟敏感的应用程序，则$$R_{min}$$可以简化为$$\frac{B+T}{B+T+L}\times MaxRate$$。

在存在大量对延迟敏感的应用程序的情况下，$$R_{min}$$可能非常小，基本上消除了RNIC资源保障。为了适应这种情况，无论有多少延迟敏感的应用程序加入系统，都可以将L=1固定，因为它们不会消耗RNIC的很多资源。我们发现该设置在实践中效果良好（第6.4节），并使其成为Justitia的默认选项。

通过提供$$R_{min}$$，Justitia然后最大化RNIC的安全资源利用率（我们称之为SafeUtil），直到延迟敏感应用程序的性能超过目标尾部延迟（Target99）。

### 4.3.2 通过参考流进行延迟监控

Justitia不会中断或与延迟敏感的应用程序交互，因为（i）它们无法使两个RNIC资源中的任何一个饱和，以及（ii）中断它们无法保持RDMA的超低延迟。

相反，每当特定接收机器上存在一个或多个对延迟敏感的应用程序时，Justitia都会维护到该机器的参考流，该参考流会以周期性间隔（默认情况下，RefPeriod=20µs）将10B消息发送到与对延迟敏感应用程序相同的接收器，以估计小消息的第99百分位（估计99）延迟。通过监控其自身的参考流，Justitia不需要等待对延迟敏感的应用程序发送足够多的样本消息以进行准确的尾部延迟估计。直接探测这些应用程序也不会增加额外的延迟。

在给定测量流的情况下，Justitia为参考流保留一个最新RefCount（=10000）测量的滑动窗口，以估计其尾部延迟。

### 4.3.3 最大化SafeUtil

使用从参考流中选择的延迟测量值，Justitia基于伪代码1中所示的算法最大化SafeUtil。为了连续更新SafeUutil，Justitia使用一个简单的AIMD方案，该方案对每个参考周期间隔的Estimitated99，如下所示。如果估计值高于Target99，Justitia将SafeUtil减少一半；SafeUtil保证至少为$$R_{min}$$。如果估计值低于Target99，Justitia将缓慢增加SafeUtil。由于SafeUtil的范围介于$$R_{min}$$到总RNIC资源之间，并且对延迟敏感的应用程序对过高的利用率非常敏感，因此我们保守的AIMD方案在实践中运行良好，该方案可以快速降低利用率以满足Target99的要求。

为了确定Target99的值，我们构建了一个延迟oracle，当没有其他背景时，它通过在集群中的所有节点上发出参考流来执行成对延迟测量。Microsoft在”Pingmesh: A large-scale system for data center network latency measurement and analysis”中采用了类似的方法，该方法在估计集群中的稳态延迟方面效果良好。我们采用这种方法可以很好地估计在隔离良好的场景下的延迟目标。

### 4.3.4 令牌生成和分发

Justitia使用多资源令牌在B带宽和T吞吐量敏感的应用程序中以公平或加权公平的方式强制执行SafeUtil。每个令牌表示固定数量的字节（令牌字节）和固定数量的消息（令牌操作）。换句话说，令牌字节的大小决定了来自带宽敏感应用程序的消息被拆分成的块大小。每t间隔生成一个令牌，其中t的值取决于SafeUtil以及每个令牌的大小。例如，在56 Gbps RNIC上，给定48 Gbps应用程序级带宽和3000万次操作/秒，如果TokenBytes设置为1MB，则我们将TokenOps设置为5000次操作，t=167µs。

Justitia守护进程每t间隔连续生成一个令牌，并根据应用程序权重$$w^i_X$$以循环方式将其分配给活动的资源匮乏应用程序。当所有应用程序的$$w^i_X=1$$时，Justitia强制执行传统的最大-最小公平性；否则，它将强制执行加权公平。每个应用程序使用下面描述的一个整形器独立地强制执行其速率。

## 4.4 Justitia整形器

在RDMA驱动程序中实现的Justitia整形器强制执行Justitia守护进程计算令牌提供的利用率限制。Justitia中有两个整形器：一个用于带宽，另一个用于吞吐量敏感的应用程序。

**连接拆分**。Justitia引入了连接拆分的概念，以提供一个接口来协调租户应用程序和RNIC之间的关系。它由消息拆分器和自定义Split QP（第5.1节）组成，用于为租户启动RDMA操作。每个应用程序的连接拆分都与Justitia守护进程协作，以透明地调整拆分消息的速度。

**对带宽敏感的应用程序进行整形**。这包括两个步骤：分割和pacing。对于任何带宽敏感的应用程序，Justitia将任何大于令牌字节的消息透明地划分为令牌字节大小的块，以确保RNIC只能看到大致相同大小的消息。为不同的RDMA verb拆分消息–例如，单边与双边–需要仔细设计（第5.1节）。

给定要发送的块，pacer通过将自身标记为活动应用程序，从Justitia守护进程请求令牌。在接收到令牌后，它传输块，直到令牌耗尽，并重复，直到没有任何东西可以发送。只有在传输了应用程序的所有拆分消息之后，才会通知应用程序消息完成。

**针对吞吐量敏感应用程序的批量整形**。这些应用程序通常处理（成批）小消息。虽然不需要进行消息拆分，但对单个小消息进行调度需要守护进程生成和分发大量令牌，这些令牌可以是CPU密集型。此外，对于小到16B的消息，这种细粒度的pacing无法保持RDMA的高消息速率。

为了解决这个问题，Justitia执行由Justitia的多资源令牌启用的批处理pacing。每个令牌授予应用程序一个固定的批量大小（令牌操作），它可以在接收下一个令牌之前一起发送。对吞吐量敏感的应用程序进行批处理消除了令牌生成和分发方面的瓶颈；它还通过统一的令牌桶降低了守护进程的CPU成本。

减轻线路阻塞。Justitia的首要目标之一是减轻带宽敏感应用程序造成的HOL阻塞，以提供可预测的延迟。为了实现这一目标，我们需要将消息分割成更小的块，并以一定的速率（强制执行SafeUtil）对它们进行调整，使它们之间有足够的间隔以最小化阻塞。然而，这种简单的方法造成了一个困境。一方面，过大的块可能无法解决HOL阻塞。另一方面，过小的块可能无法到达SafeUtil。它还导致使用旋转循环获取在非常短的时间内生成的令牌（在这种时间内上下文切换是不可承受的）而增加CPU开销。这是典型的性能隔离利用权衡的体现。我们在第5.2节中讨论了如何选择块大小。

## 4.5 动态接收端更新

Justitia依靠接收方更新在多个发送方之间进行协调，以避免RNIC资源的虚假分配。这种设计的好处有三个方面：（i）它与多个发送方协调，以提供正确的资源分配；（ii）它跟踪RDMA读取和发布，这可能与以相反方向发布RDMA写入的应用程序发生冲突；（iii）它通过使用正确的扇入信息对发送器进行速率限制来缓解接收器端引擎拥塞。

仅当检测到某个接收器的应用程序状态发生变化（即，应用程序的到达或退出）时，才会在Justitia守护进程之间传送更新。在这种情况下，选择了双边操作SEND和RECV，以便在更新到达时通知守护进程。一旦发送方检测到更改，它会通知接收方，然后将更改广播回其连接的所有发送方，以便他们能够更新正确的$$R_{min}$$。在这种情况下，$$R_{min}$$将远程资源匮乏应用程序计数视为总份额的一部分。如果本地守护进程尚未发出参考流，并且远程延迟敏感应用程序启动到接收器，则守护进程将启动新的参考流以启动延迟监控。

处理读取/READ。RDMA规范允许远程机器使用RDMA读取verb从本地机器读取。机器A发出的从机器B读取数据的RDMA读取操作与机器B的所有发送操作（如RDMA写入）竞争。因此，Justitia也必须处理远程读取。

在这种情况下，读取操作的接收器，机器B，发送更新的保证利用率$$R_{min}$$，以及更新的发送者计数（包括远程读取应用程序），如图8中的S1所示。在A接收到该利用率后，它运行RDMA READ，通常通过S2-->S5与Justitia交互，并强制执行更新的速率。

# 5 实现

我们已经在3100行C语言中将Justitia守护进程实现为一个用户空间进程，并且整形器在具有5200行C代码的单个RDMA驱动程序中实现。我们当前的实现侧重于容器/裸机应用程序。Justitia代码可从以下网址获得：https://github.com/SymbioticLab/Justitia.

## 5.1 透明拆分RDMA消息

Justitia splitter将带宽敏感应用程序的大型消息透明地划分为较小的块，以进行pacing。我们的拆分器使用称为 Split QP的自定义QP来处理消息拆分，这是在创建带宽敏感流的原始QP时创建的。相应的Split CQ用于处理完成通知。自定义完成通道用于以事件触发方式轮询这些通知，以保持较低的CPU开销。

为了处理单边RDMA操作，当检测到大于TokenBytes的消息时，我们将原始消息划分为块，并仅将最后一个块发布到应用程序的QP（图9）。其余的块被发布到Split QP。Split QP确保在应用程序的QP处理最后一个块之前，所有块都已成功传输。双边RDMA操作（如发送）以类似的方式处理，对于块大小更改和接收请求，附加的流控制消息将在接收方预发布。

## 5.2 确定带宽目标的令牌大小

确定SafeUtil的关键步骤之一是确定每个令牌的大小。因为RNIC可以成为较小消息的吞吐量限制，而不是带宽限制，所以我们不能使用任意小的消息来解决HOL阻塞。同时，给定利用率目标，我们希望使用最小的TokenBytes值来实现该目标，以减少HOL阻塞，同时最大限度地提高利用率。

我们观察到（i）这是RNIC特有的特性，（ii）RNIC类型的数量很少，而不是使用另一个类似目标的过程来动态确定。考虑到这一点，我们维护了一个预先填充的字典，以存储最小的令牌大小，当针对不同延迟目标以有节奏的批发送时，该令牌大小可以饱和给定的速率（以强制执行SafeUtil）；Justitia只是在运行时使用映射。当不存在对延迟敏感的应用程序时，将使用较大的令牌大小（1MB）。否则，Justitia会根据当前的SafeUtil值在字典中查找令牌大小。这很有效，因为SafeUtil越低，实现这种SafeUutil所需的块大小就越小，并且有助于减轻HOL阻塞。基于我们的微基准（图10），当存在对延迟敏感的应用程序时，我们选择5KB作为块大小。

# 6 评价

在本节中，我们将评估Justitia在InfiniBand和RoCEv2上为延迟、吞吐量和带宽敏感的应用程序提供多租户支持的有效性。为了测量延迟，我们连续运行了5次，并给出了它们的中值。当误差条太接近中间值时，我们不显示误差条。

我们的主要发现可以总结如下：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">Justitia可很好地扩展到大量应用程序，并适用于各种设置（第6.2节）；它补充了DCQCN和硬件虚拟通道（第6.3节）。
</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l <span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">Justitia的优势适用于许多对延迟和带宽敏感的应用程序（第6.4节）、incast场景（第6.5节）和意外网络拥塞（第6.6节）。
</span>

Justitia参数的详细灵敏度分析见附录D。

## 6.1 提供多租户支持

我们首先回顾第3节中的场景，评估Justitia如何在不同的RDMA应用程序之间实现共享策略。我们使用与第3节中相同的设置。除非另有规定，我们在InfiniBand和RoCEv2上为延迟敏感应用程序设置Target99=2µs。Justitia在100 Gbps网络中也运行良好（附录C.1）。除非另有规定，否则所有应用程序共享相同权重的$$R_{min}$$将作为默认策略强制执行。

可预测的延迟。延迟敏感应用程序在与带宽敏感应用程序竞争时受到的影响最大。在Justitia的存在下，InfiniBand和RoCEv2的中位和尾潜伏期均显著改善（图11a）。由于实施了$$R_{min}$$，对带宽敏感的应用程序将接收一半的容量（图11b）。

接下来，我们评估当延迟目标设置为松弛的值（Target99=10µs）时Justitia的表现（图12）。对于稍高的Target99，Justitia最大限度地提高了利用率，说明分割和pacing确实是有益的。
<div align="center"> <img src="https://ngdcn.com/zb_users/upload/2022/10/202210082128587928985.png"/> </div>

**公平带宽和吞吐量共享**。Justitia确保带宽敏感的应用程序以较小的带宽开销（InfiniBand上小于6%，RoCEv2上小于2%）获得相等的共享，而不管其消息大小和使用中的QP数量如何（图13）。当将Justitia应用于吞吐量敏感或延迟敏感的应用程序时，开销可以忽略不计（图14）。

Justitia的优势也扩展到了带宽敏感的应用场景。在这种情况下，它可以确保双方都获得大约一半的资源。图15说明了这种行为。在InfiniBand和RoCEv2中，吞吐量敏感的应用程序能够实现其自身单独运行时原始消息速率的一半（图15a）。另一方面，对带宽敏感的应用程序被限制为其原始带宽的一半（图15b）。

**Justita和真实世界的RDMA应用程序**。为了证明Justita可以隔离高度优化的真实世界应用程序，我们使用DARE和Crail进行了实验。。由于Justitia的高透明度，我们不需要在Crail中进行任何源代码更改（因为它默认是带宽敏感的），我们只通过将其标记为延迟敏感来更改DARE。

从这些实验中，我们发现Justitia改进了延迟敏感应用程序的隔离，同时还保留了后台存储应用程序的高带宽。图16描绘了在使用第3.2节中相同的设置应用Justitia后，DARE和Crail的性能。我们观察到，使用Justitia，DARE的性能接近于单独运行，即使在与Crail并排运行时，与基线场景相比，Justitia将DARE的尾部延迟性能提高了3.4倍，而Crail也达到了其原始吞吐量性能的81%。这接近于Crail原始吞吐量的8/9的预期吞吐量，因为在本实验中，Justitia将Crail之上的8个并行写操作视为单独的应用程序。

Justitia将FaSST的性能隔离提高了2.5倍吞吐量，将eRPC提高了32.2倍尾部延迟。更多详情见附录C.2。

## 6.2 Justitia进一步讨论

**可扩展性和速率一致性**。图17a显示，随着对带宽敏感的应用程序数量的增加，所有应用程序都使用Justitia接收相同的带宽，总带宽接近线路速率。Justitia还确保所有吞吐量敏感的应用程序发送的消息数量大致相等（图17b）。

**CPU和内存消耗**。Justitia daemon为每个节点使用一个专用CPU核来生成和分发令牌。其内存占用并不显著。

**不同的消息大小**。Justitia可以为延迟敏感的应用程序提供范围广泛的消息大小隔离（图18）。对带宽敏感的应用程序在所有情况下都接收一半的带宽。

# 6.3 Justitia+X

Justitia+DCQCN。我们在本文中发现的异常现象并非源于网络拥塞，而是发生在终端主机上。我们发现DCQCN不适用于后期和吞吐量敏感的应用程序（图19、20、21）。Justitia可以补充DCQCN，并将延迟提高8.6倍，吞吐量提高2.6倍。

Justitia+硬件虚拟通道。尽管RDMA标准支持多达15个虚拟通道用于分离流量类别，但它们只映射到极少数硬件整形器和/或优先级队列（我们的RoCE NIC中有2个队列），在共享环境中很少足够。此外，RNIC中的硬件速率限制器在设置新速率时速度较慢（在我们的设置中为2毫秒），因此很难使用真正的动态安排。此外，希望在每个优先级队列中实现隔离，因为这些硬件资源通常用于提供不同级别的服务质量，其中有许多应用程序。

在本实验中，我们展示了有限数量的硬件队列如何不足以提供隔离，以及Justitia如何在这种情况下提供帮助。我们运行三个应用程序，三种类型各一个（图22）。虽然延迟敏感的应用程序在其自己的类中保持隔离，但带宽和吞吐量敏感的应用软件在同一类中竞争。因此，后者观察到吞吐量损失（类似于图15）。Justitia可以有效地在共享队列中对带宽和吞吐量敏感的应用程序之间提供性能隔离。

## 6.4 在更多的竞争者中隔离

我们关注Justitia在隔离具有不同需求和性能特征的许多应用程序方面的有效性。具体来说，我们考虑了8个带宽敏感的应用程序—2个消息大小分别为1MB、10MB、100MB和1GB的应用程序，以及8个延迟敏感应用程序。我们在图23中测量了所有应用程序处于活动状态时的延迟和带宽。Target99设置为2µs，并收集了2000万个样本进行延迟测量。

如果没有Justitia，对延迟敏感的应用程序会受到很大的性能影响：每个应用程序的平均延迟和第99百分位延迟分别为1.3和1.4µs（图3a和3b）。对于带宽敏感的应用程序，它们分别恶化了71.4倍和79.8倍。Justitia将延迟敏感应用程序的中值和尾部延迟分别提高了26.5倍和12.7倍，同时保证了所有应用程序之间的R_{min}。

## 6.5 处理接收端更新的Incast

到目前为止，我们主要关注网络结构不是瓶颈的主机端RNIC竞争。现在，我们评估Justitia如何利用接收方更新来处理RoCEv2和InfiniBand中的接收方incast，前者使用DCQCN，后者使用其基于信用的本地流控制。在本实验中，使用了33个发送方，前32个发送方连续启动带宽敏感应用程序，向单个接收器发送1MB消息。同时，最后一个发送者启动一个对延迟敏感的应用程序，并将消息发送给同一个接收者。如第4.5节所述，每当发送方应用程序启动或退出时，接收方的Justitia守护进程都会向所有发送方发送更新，从而在前32个发送方中的每一个都能保证1/32线速率。

图24显示了该实验的结果，该结果表明，即使在结构级拥塞对参考流延迟测量产生影响之后，Justitia仍然减少了尾部延迟。由于监控的延迟未达到目标，因此所有带宽敏感的应用程序都以最低保证速率发送。然而，Justitia仍然实现了高聚合带宽，因为这大于公平份额。这表明Justitia补充了拥塞控制，并通过缓解接收方RNIC拥塞进一步提高了延迟敏感应用程序的性能。

我们还在附录E.4中讨论了关于大规模incast场景中参考流影响的常见问题。

## 6.6 Justitia出现意外的网络拥塞

当网络内部出现拥塞时，通过网络的所有流量都将经历延迟增加，包括Justitia生成的作为延迟信号的数据包。因为今天的交换机和NIC没有报告它们各自对端到端延迟的贡献，Justitia无法区分它们。然而，在实践中，这不是问题，因为相同的响应适用于两种情况。

为了评估Justitia在这种情况下的表现，我们利用CloudLab上的两个互连ToR交换机进行了实验。每个ToR交换机都连接有服务器，每台服务器的线路速率为10Gbps。实验拓扑如图25a所示。在这种拓扑结构中，有一个第三核心交换机，通过容量为160 Gbps的链路连接到每个ToR交换机。在本实验中，我们在集群中的所有服务器上启用DCQCN，并在ToR交换机上启用ECN标记。

为了创建拥挤的ToR上行链路，我们启动了24个带宽敏感应用程序，每个应用程序从一个机架下的24台服务器（S1-S24）向另一个机架上的其他24台服务器发出1MB消息，并且没有一台服务器运行Justitia。同时，我们在Justitia控制的一对服务器（S25和R25）之间发布了8个带宽敏感应用程序和1个延迟敏感应用程序。图25显示了应用和不应用Justitia时的性能。即使在结构拥塞超出Justitia控制的情况下，我们也可以看到Justitia仍然可以正常工作，并且与仅使用拥塞控制（DCQCN）相比，Justitia仍提供了额外的性能隔离优势。

# 8 结束语

我们已经证明，RDMA基于硬件的内核旁路机制导致缺乏多租户支持，这导致跨InfiniBand、RoCEv2和iWARP以及10、40、56和100 Gbps网络的带宽、吞吐量和延迟敏感RDMA应用程序之间的性能隔离异常。我们介绍了Justitia，它将基于发送方的资源中介与接收方更新、带消息级整形的连接分割和被动机器级延迟监控相结合，并将尾部延迟目标作为单个旋钮，为支持RDMA的网络提供网络共享策略。

# 参考文献

Zhang, Yiwen et al. “Justitia: Software Multi-Tenancy in Hardware Kernel-Bypass Networks.” NSDI (2022).

> 译者注：由于本人水平有限，如有纰漏，请以参考文献文章为准。

<font color=red>**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**</font>