理解 RDMA 微架构资源以实现性能隔离
发表会议: 第20届 USENIX 网络系统设计与实现研讨会 (NSDI 2023), 2023年4月17--19日, 美国波士顿
**原文链接
摘要
近年来，RDMA 在云端得到广泛采用，以加速第一方工作负载并通过释放 CPU 周期来节省成本。现在，云服务提供商正致力于在通用访客虚拟机中支持 RDMA，以使第三方工作负载受益。为此，云服务提供商必须提供强大的性能隔离，以确保一个租户的 RDMA 工作负载不会对另一个租户的 RDMA 性能产生不利影响。尽管人们在公共云中的网络性能隔离方面做出了许多努力，但我们发现，由于 RDMA 复杂的网卡微架构资源（例如网卡缓存），它带来了独特的挑战。
在本文中，我们旨在系统地理解 RNIC 微架构资源对性能隔离的影响。我们提出了一个模型来表示 RDMA 操作如何使用 RNIC 资源。利用该模型，我们开发了一个测试套件来评估 RDMA 性能隔离解决方案。我们的测试套件可以在各种场景中破解所有现有解决方案。我们的研究结果得到了最大的 RDMA 网卡供应商之一的确认和复现。最后，基于测试结果，我们总结了设计未来 RDMA 性能隔离解决方案的新见解。
1 引言
在共享计算基础设施上多路复用来自不同租户的工作负载，开启了现代云计算时代。全球云基础设施收入已超过 4000 亿美元，并预计在未来十年内增长至约 1 万亿美元 7。众所周知，让不同租户的工作负载共享计算资源可能导致不可预测的应用性能干扰 12,18,66 和隐私泄露 32,39。这推动了大量专注于云中性能隔离的研究，特别是针对具有严格服务级别目标的性能关键型应用 11,12,18,41,63,66,70。实践中的最新技术也取得了显著进步：CPU 供应商甚至实现了硬件机制来控制和隔离对 CPU 缓存的访问 20。通过共享资源的侧信道正随着时间的推移而被修补 39。
在本文中，我们研究一种特定的硬件设备：RDMA 网卡（RNIC）。RDMA 将网络协议栈从操作系统内核卸载到网卡硬件，以提供高吞吐量和超低处理延迟，且 CPU 开销接近零。RDMA 已大规模部署在数据中心中，以提高性能并释放 CPU 核心用于存储和机器学习等第一方工作负载 14,17,38,51。现在，云服务提供商正致力于在通用访客虚拟机中支持 RDMA，以使第三方工作负载受益。为此，云服务提供商必须为共享同一 RNIC 的租户提供强大的性能隔离。
人们已经做了许多努力来改善公共云中的网络性能隔离，特别关注带宽和数据包处理能力 3,15,16,25,34,62,64。然而，由于 RDMA 独特而复杂的网卡微架构资源（例如网卡缓存和处理单元），它带来了新的挑战。研究界已经知道这些资源的存在及其对性能的影响 29,33。为了避免性能异常，开发人员精心设计 RDMA 系统以避免耗尽这些微架构资源 5,9,10,27,30,50,61。我们的研究角度不同：我们从公共云提供商的角度研究这些微架构资源如何影响 RDMA 性能隔离。云提供商不了解也无法控制租户的 RDMA 应用，而租户可以任意方式消耗 RNIC 微架构资源。
为了证明 RNIC 微架构资源对性能隔离的显著影响，我们测试了最先进的方法：使用 SR-IOV 与分离的硬件流量类别（HW TC）。SR-IOV 和 HW TC 都是商用 RNIC 上可用的硬件机制。HW TC 利用 RNIC 中的多个硬件队列（通常为 8 个队列）。我们可以为每个租户应用分配一个队列。我们在两台虚拟机之间运行一个受害者流量，使用 ib_write_bw，这是 Perftest 56 中的标准 RDMA 带宽测试工具。每台虚拟机位于不同的服务器上，这两台服务器配备 100 Gbps NVIDIA ConnectX-5 RNIC。图 1 显示了带宽。带宽测试达到 80 Gbps。我们在每台服务器上启动一台虚拟机作为攻击者（即有缺陷或恶意的租户应用），并启用性能隔离，为受害者和攻击者分配总带宽的一半。受害者流量降至 50 Gbps，这是预期的。然而，当我们启动一个精心设计的攻击者流量，仅 1 Gbps，故意耗尽 RNIC 微架构资源之一时，受害者立即降至 2 Gbps，违反了性能隔离保证（即受害者保证的 50 Gbps 网络带宽）。
我们开发了一组实验来研究不同类型的 RDMA 操作如何使用 RNIC 微架构资源。我们的实验揭示了几个有趣的发现，包括：（1）异常或错误处理会暂停 RNIC 的流水线，并导致其他租户的性能急剧下降。（2）控制动词会导致缓存未命中严重增加，并损害其他租户的性能。（3）数据动词会耗尽不同类型的微架构资源，并违反性能隔离。据我们所知，我们是第一个系统研究所有类型的控制动词和异常对 RDMA 微架构资源消耗影响的人。
我们利用这些发现创建了一个 RDMA 操作模型，来描述 RDMA 动词操作与所消耗的微架构资源之间的关系。我们的模型使我们能够理解如何耗尽每个 RNIC 资源。利用该操作模型，我们创建了第一个测试套件 Husky，以系统测试和评估 RNIC 性能隔离解决方案。不幸的是，在商用 RNIC 上运行我们的测试套件揭示了一个坏消息：目前没有解决方案可以提供 RNIC 性能隔离。我们已经将所有发现报告给三大 RNIC 供应商：NVIDIA、Chelsio 和 Intel。我们的结果得到了最大的 RDMA 网卡制造商之一 NVIDIA 的完全复现和确认。最后，我们提出了关于未来应如何构建性能隔离解决方案的新见解。我们希望这些见解能够有益于未来的 RNIC 设计和 RDMA 软件开发。
本文做出了以下贡献：
- 我们识别了 RDMA 操作与 RNIC 微架构资源之间的多种交互，包括以前未知的错误处理和控制操作的影响。
- 我们引入了第一个 RDMA 操作模型，来描述 RNIC 微架构资源如何在动词操作（标准 RDMA 编程 API）中被消耗，以及为什么这些微架构资源会影响性能隔离。
- 我们构建了第一个系统测试和评估 RNIC 性能隔离解决方案的测试套件。我们表明，没有任何现有性能隔离解决方案能够通过我们的测试套件。Husky 测试套件可在 https://github.com/host-bench/husky 获取。
这项工作表明，在公共云中为 RDMA 提供性能隔离比人们想象的要困难得多。未来的 RDMA 性能隔离解决方案必须有更高的标准：它们应仔细考虑 RNIC 微架构资源，并通过系统基准测试进行评估。
2 背景与动机
我们首先介绍公共云中网络性能隔离的背景知识。然后我们介绍 RDMA，并讨论 RDMA 网络性能隔离带来的新挑战。
2.1 公共云中的网络性能隔离
云中的租户主要对两类网络资源造成争用。第一类也是最明显的一类是网络结构中的带宽。为了缓解租户之间的带宽争用，一系列工作 58,60,62 静态限制每个租户的带宽。另一系列工作 1,3,4,6,16,24,25,37,58,59,68 为每个租户提供最小带宽保证，并允许租户使用空闲带宽容量。第二类资源是端主机的数据包处理资源。每个数据包的处理成本取决于许多因素，例如缓存未命中和要执行的操作。最近，PicNIC 34 为这种软件数据包处理提供了隔离。人们还利用专门的硬件来实现相同的目标 64。
值得注意的是，网络性能隔离与网络虚拟化非常不同。网络虚拟化编排网络资源，为每个租户提供独立网络的幻觉。一个租户不应影响另一个租户的网络连通性。网络虚拟化的目标是实现低开销 19,31,57。相比之下，网络性能隔离侧重于如何管理资源争用，以确保租户能够实现保证的性能。
2.2 RDMA 概述
RDMA 允许网卡在导线和应用内存之间直接传输数据。网络协议在网卡中实现。图 2 展示了 RDMA 工作流的概述。它将标准 RDMA 编程接口（即动词，verbs）分为两类：控制类和数据类。应用首先需要调用多个控制动词来分配必要的对象，例如队列对（QP）和完成队列（CQ），以建立可靠连接（RC）、不可靠连接（UC）或不可靠数据报（UD）传输端点。然后应用需要注册一个内存区域（MR）。该注册实质上将内存固定在主机 DRAM 中，并获取从虚拟地址到物理地址的映射，从而使 RNIC 能够直接从该内存区域读取或写入。所有这些控制动词都通过以下过程处理：RDMA 的用户空间库和内核驱动程序处理动词请求，生成请求命令，将命令放入协商好的命令队列中，并响铃 RNIC 的门铃（例如内存映射寄存器）。RNIC 从命令队列中获取命令，处理它，并将响应推送回队列。然后驱动程序处理响应并将对象返回给应用。
在上述初始化之后，应用可以开始在本地和远程内存之间进行数据传输。应用可以使用几种类型的操作，例如 SEND/RECV、WRITE、READ 和 ATOMIC。我们将这些操作命名为数据动词。要发出数据动词，应用通常向其发送队列发布请求，并通过用户空间库响铃 RNIC 的门铃。然后 RNIC 解析请求，从主机内存读取数据，将数据分段为数据包，并传输数据包。此过程绕过内核。处理不同类型的请求存在某些差异。例如，对于 SEND/RECV 消息，接收方应在发送方发出 SEND 请求之前发布足够的 RECV 请求。否则，传入的 SEND 请求可能会被丢弃或需要重传，因为接收方 RNIC 缺乏接收请求来处理它们，这被称为接收未就绪（RNR）错误。对于向远程端 WRITE/READ 数据或执行 ATOMIC 操作，发送方应指定正确的远程虚拟地址和内存密钥。无效地址或错误密钥将触发内存保护错误，并导致 QP 转换到错误状态。
2.3 为什么 RDMA 性能隔离很难？
如上所述，RDMA 将许多主机网络功能卸载到 RNIC，RNIC 有许多不可见的硬件组件，每个组件都可能单独成为性能瓶颈。图 3 显示了商用 RNIC 的硬件组件。我们根据 NVIDIA 公开可用的文档绘制了此图 44,46,48。除了数据包缓冲区（TX/RX Buffer）之外，RNIC 还具有多个处理单元（PU）和许多类型的内部缓存。每个内部缓存用于存储特定类型的元数据。例如，在 NVIDIA RNIC 中，互连上下文内存（ICM）缓存存储 QP 上下文；内存转换表（MTT）和内存保护表（MPT）存储内存地址转换和保护信息的条目；工作队列条目（WQE）缓存存储预取的发送 WQE 和发布的接收 WQE。由于这些缓存源于设计需求，其他 RNIC 也包含类似的组件。我们基于 CPU 硬件的类比，将这些 RNIC 硬件组件命名为微架构资源。CPU 设计符合标准指令集架构（例如 ARM、x86），但 CPU 设计人员可以做出微架构级别的决策，例如缓存的层级数和缓存大小。RNIC 类似，因为 RNIC 供应商必须为 RDMA 应用开发人员提供相同的编程接口，但供应商可以决定这些微架构级别的细节，例如 RNIC 缓存。
许多先前的努力已经识别了这些微架构资源对 RDMA 应用性能的一些影响。例如，5,29,50 发现 RNIC 会缓存 QP 上下文。QP 上下文缓存未命中可能触发额外的 PCIe 往返，以便 RNIC 从主机 DRAM 获取上下文，从而降低应用性能。例如，200 个连接可能导致 NVIDIA ConnectX-3 网卡上的请求速率下降 90% 5。然而，这些努力从应用开发人员的角度研究微架构资源。在性能下降后，他们识别瓶颈资源，寻找更有效的数据动词使用方法，并相应地修改其应用。
然而，在公共云中，云提供商无法控制租户的应用。因此，租户可以随意消耗 RNIC 的微架构资源，甚至恶意地消耗。因此，从云提供商的角度来看，我们需要了解大多数（如果不是全部）RDMA 动词的微架构资源消耗，而不仅仅是常见的数据动词。只有具备这些知识，我们才能正确地将 RNIC 的微架构资源分配给不同租户，以提供可预测的性能。
3 RNIC 微架构资源
在本节中，我们介绍对目前我们所知的所有 RNIC 微架构资源的研究。先前的工作已经识别了几种特定形式的资源争用。但我们这里的目标是系统研究所有可能类型的资源争用。对于每个微架构资源，我们研究它如何被三类 RDMA 操作消耗：（1）为应用分配对象的控制动词（例如 ibv_create_qp），（2）启动数据传输的数据动词（例如 ibv_post_send），以及（3）处理异常或错误的异常处理操作（例如 RNR 错误）。由于篇幅限制，我们首先介绍几个对 RNIC 性能隔离有重大影响的关键发现。之后，我们总结其他几个发现。我们在附录 B 中展示了 NVIDIA 对这些发现的详细分析。
3.1 方法论
我们的发现集中在如何通过动词接口 21（标准 RDMA 编程 API）耗尽 RNIC 微架构资源。对于每个关键发现，我们用一个具体的设置来演示它，该设置包括一个受害者工作负载和一个攻击者工作负载。虽然我们使用了攻击者这一术语，但攻击者租户并不会通过漏洞未经授权访问其他租户。相反，攻击者只是一个发出标准 RDMA 动词的正常 RDMA 应用。每个租户有一个客户端和一个服务器。受害者和攻击者的客户端位于同一台物理机上，共享同一个 RNIC。受害者和攻击者的服务器位于另一台物理服务器上。在测量期间，我们不启用任何隔离机制。我们将在第 5 节研究现有的性能隔离解决方案。
我们专注于受害者和攻击者之间通过耗尽微架构资源而产生的性能干扰。我们首先仅运行受害者，以饱和链路带宽容量（每秒比特数）或 RNIC 的最大请求速率（每秒请求数）。然后我们启动攻击者，并测量受害者和攻击者的两个指标。如果没有微架构资源争用，两个租户的性能指标之和应符合规范中的 RNIC 限制。现代 RNIC 规定了其带宽容量和请求速率限制。如果两个租户的性能指标之和低于两个规定的限制，我们将其归因于微架构资源的争用。例如，假设没有攻击者，受害者可以达到 100 Gbps。然而，有了 X Gbps 的攻击者，受害者降至 Y Gbps，且 X + Y < 100。让我们还假设总请求速率低于 RNIC 规范。在这种情况下，我们得出结论某些微架构资源已成为瓶颈。除非另有说明，流量使用 RC 连接。
我们测试了四种类型的 100 Gbps RNIC：NVIDIA ConnectX-5 EN 和 ConnectX-6 Dx、Chelsio T62100-LP-CR 和 Intel E810。NVIDIA 网卡运行 RoCE，Chelsio 网卡运行 iWARP。Intel E810 同时支持 RoCE 和 iWARP，但我们目前仅测试其 RoCE 实现。RoCE 和 iWARP 是在基于以太网的网络上运行 RDMA 的两种标准方式。我们的测试平台由两台服务器组成，每台配备一个 RNIC，两个 RNIC 通过 100 Gbps 交换机连接。对于 NVIDIA RNIC，我们可以通过其网络适配器管理工具 NEO-Host 44 访问其硬件计数器，例如缓存未命中计数器。这些硬件计数器使我们能够精确指出哪个资源被过度订阅。例如，当 ICM 缓存未命中计数器随着某个应用工作负载迅速增加时，我们便能得知该工作负载大量使用了此缓存，从而使其被过度订阅（oversubscribed）。由于其他 RNIC 不暴露此类计数器，我们基于其端到端性能指标（例如带宽）对其他 RNIC 进行实验。
3.2 网卡缓存
我们知道 RNIC 至少有三种类型的缓存，如图 3 所示。RNIC 在这些缓存中存储几种类型的元数据以加速请求处理，例如 ICM 缓存中的 QP 上下文。先前的工作已经识别了由具有特定模式的数据动词引起的一些 RNIC 缓存争用问题。例如，同时在许多 RC QP 上传输小消息以及对大量内存区域的随机访问可能导致某些类型的严重缓存未命中（例如 ICM 和 MTT/MPT）29,53。ScaleRPC 5 发现这种可扩展性问题可以将 WRITE 请求速率降低 90%。
除了这些众所周知的问题之外，我们观察到了一种新的、甚至更严重的方式来耗尽缓存：
关键发现 #1：控制动词可能导致过多的缓存未命中和严重的性能下降。 控制动词（例如 ibv_reg_mr）用于创建和销毁 MR 和 QP 等对象，这些对象将被数据动词用于传输数据。据我们所知，没有研究探讨控制动词如何消耗 RNIC 微架构资源。我们发现控制动词很容易触发过多的缓存未命中，从而降低带宽和请求速率。
我们在 NVIDIA ConnectX-5 RNIC 上用一个简单的实验来证明这一发现。我们让受害者租户使用 6 个核心，每个核心 16 个连接，发出 512B WRITE 请求以耗尽 RNIC 的带宽容量（即 100 Gbps）。表 1 显示了结果。受害者可以以 17.2% 的 MTT 缓存未命中率实现 96.6 Gbps。在如此缓存未命中率下，受害者仍然可以达到线速，因为 QP 多路复用和 RNIC 流水线设计可以在一定程度上掩盖缓存未命中的开销。我们让单线程攻击者持续在受害者的发送端使用 ibv_reg_mr 注册内存区域（MR）（每秒约 5K 次注册）。在这种情况下，受害者的带宽几乎不受影响，保持在 95.9 Gbps，未命中率略微增加到 22.9%。然而，如果攻击者持续注销 MR，我们可以看到对受害者的显著影响：缓存未命中率增加到 49.1%，带宽降至 48 Gbps。在如此高的缓存未命中率下，开销变得显著，再也无法被 RNIC 处理流水线掩盖。值得注意的是，攻击者不需要发出任何数据动词，因此攻击者根本不消耗网络带宽或请求速率。幸运的是，我们观察到这种干扰在接收端可以忽略不计。
与数据动词相比，我们发现控制动词更容易导致性能干扰。为了过度填充缓存资源，我们需要启动足够多在途数据动词，并强制它们随机访问大量对象（例如 MR）。例如，在 NVIDIA ConnectX-5 RNIC 上，我们发现需要 6 个线程通过 96 个 QP 访问超过 18K 个 MR，才能导致足够严重的 MTT 缓存未命中，使带宽降低 40.1%。我们相信由于数据动词导致的缓存未命中将变得不那么严重，因为 RNIC 供应商不断增加片上缓存资源。相比之下，控制动词通过其特殊语义影响缓存资源，而不是简单地消耗它们，因此控制动词的影响可能难以缓解。例如，我们推测 MR 注销可能会使整个 MTT/MPT 缓存失效，以避免访问过时的 MR。这会导致访问其他 MR 时的缓存未命中。
我们还在 Chelsio 和 Intel 网卡上进行了相同的实验，并观察到了类似的结果。
3.3 处理单元
RNIC 有几个处理单元（PU）来处理动词请求。由于缺乏公开可用的计数器来监控 PU 的状态，我们使用请求速率作为衡量不同动词如何消耗 PU 的指标。我们总结了以下两个关键发现：
关键发现 #2：不同数据动词之间的性能干扰取决于动词的复杂性。 不同的数据动词具有不同的复杂性。简单的动词，如 send 和 read，只在机器之间复制数据。复杂的动词，例如 fetch_and_add，自动将 64 位值添加到远程地址的内存中。此操作利用 PCIe 功能（例如读-修改-写事务），还可能获取目标地址上的锁。这些复杂的动词消耗更多的 PU 资源，导致更低的请求速率 29。我们在这里的新发现是，这种资源消耗差异也可以通过资源耗尽为性能干扰打开一条新途径：当受害者与密集使用复杂动词的攻击者共处时，受害者的性能可能会受到大幅惩罚。
为了理解这种影响，我们首先测量数据动词在与其他数据动词竞争时的请求速率。我们从 NVIDIA 100 Gbps ConnectX-5 RNIC 开始。我们为每个测试设置两个工作负载，每个工作负载在 8 个专用 CPU 核心上运行 8 个 QP，以饱和 RNIC 的速率。为了避免 RNIC 严重的缓存未命中，我们总共只使用 128 个 QP 和 16 个 MR。在所有 PU 测试中，我们观察到不到 1% 的缓存未命中。为了避免达到带宽容量限制，我们将所有数据动词的请求大小设为 8B。我们首先设置一个工作负载（受害者）使用特定类型的数据动词，然后使用不同类型的数据动词设置攻击者工作负载。我们在图 4 中显示了它们的请求速率结果。
我们的第一个收获是，除了 ATOMIC 操作 29 之外，READ 操作也比 SEND/RECV 和 WRITE 更昂贵。当它们单独运行（作为受害者流量）时，FAA 和 CAS 分别仅达到 5.2 Mrps 和 4.8 Mrps。READ 达到约 60 Mrps。SEND 和 WRITE 可以达到超过 90 Mrps。
第二个也是更重要的收获是，不同数据动词操作组合之间的争用行为可能会有所不同。例如，当受害者单独运行 READ 工作负载时，它可以达到 60 Mrps。如果攻击者运行 CAS 工作负载，受害者的请求速率立即降至 3 Mrps。如果攻击者运行 READ 工作负载，受害者的请求速率仅降至 30 Mrps。这意味着复杂的动词（例如 CAS）可以消耗更多资源并惩罚其他共处的动词工作负载。我们想强调的一个非直观行为是，如果攻击者在此设置下运行 SEND 或 WRITE 工作负载，运行 FAA 或 CAS 的受害者的请求速率实际上可能会增加¹。
我们还在 100 Gbps Chelsio T62100-LP-CR RNIC 上进行了类似的测试，结果如图 5 所示。这款 iWARP RNIC 不支持 ATOMIC 操作。我们观察到，与 RoCE RNIC 相比，这款 iWARP RNIC 对所有类型数据动词的请求速率都较低，这与先前工作的发现一致 8,49,71。我们发现 Chelsio RNIC 上数据动词之间的争用也有所不同。例如，在没有干扰的情况下，带有 WRITE 工作负载的受害者可以达到 4.76 Mrps。攻击者可以使受害者的请求速率在使用 SEND 工作负载时下降 55.0%，在使用 READ 工作负载时下降 73.1%。具体模式与 NVIDIA RNIC 不同，但这个结果仍然证明了我们的关键发现：不同数据动词的 PU 开销各不相同。
关键发现 #3：错误处理可能暂停 RNIC 处理单元并挂起所有应用。 RNIC 需要处理几种类型的错误，包括传输超时（响应方不发送 ACK 或 NACK）、接收未就绪（RNR）错误（响应方没有足够的接收请求来处理到达的发送请求）、本地或远程保护错误（发布的请求不引用有效的本地或远程内存区域）以及本地操作错误（在错误类型的 QP 上操作操作码）。处理这些错误需要 RNIC 处理单元的资源，某些错误对 RNIC 来说处理起来可能很昂贵。
在 NVIDIA ConnectX-5 和 ConnectX-6 RNIC 上，我们发现处理 RNR 错误可以完全暂停 RNIC 处理单元。对于受害者，我们使用 Perftest 56 在单个 QP 上保持 128 个在途 64KB WRITE 请求，以饱和带宽容量。对于攻击者，我们只使用单个 QP（即表中的 SEND 应用）来保持只有一个在途 4KB SEND 请求，以消耗少量带宽。如表 2 所示，如果 SEND 应用正常生成流量（例如响应方发布足够的接收请求），它消耗 4 Gbps 带宽，受害者的带宽仅下降约 3.5 Gbps。然而，当 SEND 应用触发 RNR 错误（例如响应方不发布任何接收请求）时，SEND 应用和受害者都被暂停。我们测试了两个方向的 RNR 错误，并看到了相同的结果。原因是 RNR 接收方的 RNIC 被暂停，RNIC 甚至无法处理 ACK 数据包。因此，即使受害者正在相反方向发送流量，也会被暂停。
我们使用 Intel 和 Chelsio 网卡进行了相同的实验。我们观察到，对于 Intel E810，受害者的 QP 连接在数据传输期间也意外终止。幸运的是，我们没有看到 Chelsio T62100-LP-CR 存在这样的 RNR 问题。我们最好的猜测是 iWARP 设计在 TCP 之上，旨在有损结构上运行，因此它可能具有更有效的错误处理机制。
3.4 PCIe 带宽
RNIC 连接到 PCIe 控制器，并使用 PCIe 通道与 CPU 传输数据。几项先前的工作 29,34,52 已经研究了 PCIe 对网络协议栈的影响。基于现有的 PCIe 模型，我们进一步研究 RDMA 动词如何消耗甚至耗尽 PCIe 带宽。先前的工作已经识别了 RDMA 环回流量如何耗尽 PCIe 带宽 26,33。因此，我们专注于正常的 RDMA TX 和 RX 流量。
要传输 RDMA 消息，PCIe 引入了以下类型的额外字节：（1）响铃 RNIC 门铃的 MMIO（64B，取决于缓存行大小），（2）工作队列元素（WQE）（36B 或 64B），（3）PCIe 协议开销（例如 TLP 头），以及（4）缓存未命中触发的额外 PCIe 操作。我们对 PCIe 带宽的关键观察是：
关键发现 #4：只有当请求大小在特定范围内时，PCIe 带宽才会成为瓶颈。 我们只需要一个租户来证明这个关键发现。我们在 NVIDIA 100 Gbps ConnectX-5 RNIC 上运行实验。PCIe 带宽容量为 128 Gbps（PCIe Gen 3.0 x16）。我们使用跨 6 个核心的 96 个 QP 来饱和 PCIe TX 带宽。每个 QP 保持 256 个在途 WRITE 请求。我们改变请求大小，并通过读取 RNIC 的计数器来收集 NIC 和 PCIe 带宽消耗。结果如图 6 所示。我们首先观察到，当负载大小较小时，商用 RNIC 可以通过将小消息嵌入 WQE 来缓解 WQE 开销。如绿色矩形所示，当请求大小小于 28B 时，增加请求大小不会导致更多的 PCIe 带宽消耗，因为负载与 WQE 嵌入在同一个 MMIO 操作中。
我们的第二个观察是，只有当请求的负载大小在特定范围内时，PCIe TX 带宽才可能成为瓶颈。原因是短请求首先被请求速率限制，然后才耗尽 PCIe 带宽，而大请求总是被 RNIC 的带宽容量限制。我们通过理论 PCIe 消耗模型证实了这一观察，并给出了两个具体例子。我们假设网络 MTU 为 4096B，每个 PCIe 事务的最大负载为 128B（最大化 PCIe 开销的最坏设置）。TLP 开销取决于实现 52，我们假设其为 20B，这是 PCIe 3.0 设备的典型大小。传输 29 字节消息最多消耗 127 个网络字节，至少消耗 189 个 PCIe 字节 29,69。因此，要饱和链路带宽（100 Gbps），我们至少需要 148.8 Gbps 的 PCIe 带宽，这远大于 PCIe 3.0x16 的容量。附录 A 包含详细计算。我们的测量显示实际消耗可能更高，如图 6 所示。PCIe RX 带宽（即从 RNIC 到主机）的消耗模型与 TX 类似。此外，过多的缓存未命中也可能导致高 PCIe 带宽消耗，因为需要大量 PCIe 读取来获取元数据。然而，在大多数情况下，大量的缓存未命中首先会减慢 RNIC 执行速度（例如引入额外延迟），因此 PCIe 带宽消耗较少。在我们对缓存未命中的测量中，我们没有观察到 PCIe TX 带宽耗尽的情况。
理论模型和实验结果都表明，PCIe 带宽可能成为瓶颈，但仅限于特定的请求大小范围。
3.5 其他发现
我们还有几个其他有趣的发现。鉴于篇幅限制，我们在这里仅简要介绍它们。然而，我们确实使用这些发现来指导第 4 节的测试套件设计。
其他发现 #1：数据动词争用不同的 RNIC 缓存。 我们使用不同的数据动词进行可扩展性测试，并观察到不同类型的缓存争用。例如，大量发出 READ 和 WRITE 的 RC QP 主要会导致 ICM 缓存未命中。大量发出 SEND/RECV 请求的 UD QP 或许多发出 ATOMIC 请求的 RC QP 可能导致严重的 RECV WQE 缓存未命中。这一观察表明，数据动词对缓存的争用方式不同，类似于对 RNIC PU 的争用。
其他发现 #2：对许多对象（QP、CQ、MR）的广泛访问会导致 ICM 缓存未命中。 可扩展性问题已得到充分研究，但我们的测量揭示了新的观察结果。除了 QP 和 MR 之外，完成队列（CQ）的上下文也存储在 ICM 缓存中。因此，访问大量 CQ 也可能触发严重的 ICM 缓存未命中。此外，分配大量这些对象不一定会导致严重的 ICM 缓存未命中。对对象的广泛访问（即局部性差）是触发严重 ICM 缓存未命中和性能下降的关键。
其他发现 #3：控制动词的影响受到其内核参与的限制。 我们观察到所有控制动词首先由内核驱动程序处理，从而导致昂贵的上下文切换。这些控制动词的执行速率通常受到内核的限制，而不是 RNIC 处理。因此，控制动词对耗尽 RNIC PU 的影响有限。然而，它们仍然可能造成显著的性能干扰，并通过触发严重的缓存未命中影响其他应用，如我们的关键发现 #1 所示。
3.6 资源消耗模型
我们在图 7 所示的 RDMA 操作模型中总结了我们的发现。该模型描述了动词操作大量消耗哪种微架构资源。请注意，动词操作也可能使用我们实验未捕获的其他微架构资源。这是因为这些资源的使用量较低，不会导致资源争用。该模型是定性的：由于我们无法了解专有 RNIC 硬件的内部情况，我们不试图理解确切的资源使用情况。例如，我们知道某种流量模式可以触发某种类型的缓存未命中，但我们无法弄清楚缓存的总大小或操作消耗了多少缓存。即便如此，我们表明该模型足够强大，可以帮助我们创建第一个用于 RNIC 性能隔离的测试套件，并且可以捕获能够破解现有性能隔离解决方案的广泛工作负载。
4 Husky 测试套件
在我们理解了不同的 RDMA 操作如何使用这些微架构资源之后，我们可以设计一个测试套件来评估性能隔离解决方案。我们的目标如下：给定一个 RNIC 硬件和一个性能隔离解决方案，我们希望找到一组攻击者和受害者的工作负载组合，能够打破性能隔离。为了完整性，我们需要检查不同的受害者工作负载，因为不同的受害者工作负载对不同微架构资源的耗尽敏感。
我们的测试套件必须是通用的：我们将用它来测试不同 RNIC 上的各种 RNIC 性能隔离解决方案。这意味着我们不能依赖特定供应商的工具和功能，例如 Mellanox Neo-Host 44。此外，不同的 RNIC 具有不同数量的微架构资源。现有的性能隔离解决方案可能只能缓解特定资源上的争用。
为此，我们构建 Husky 来系统测试和评估 RNIC 性能隔离解决方案。Husky 针对四种类型的资源：NIC 带宽、PCIe 带宽、NIC PU 和 NIC 缓存。对于每种资源，我们设计了具有不同类型行为（例如控制动词）的合成工作负载来耗尽该资源。更具体地说，我们使用不同操作码（例如 WRITE）的长消息来耗尽 NIC 带宽；我们使用环回流量和特定消息模式（来自关键发现 #4）来耗尽 PCIe 带宽；我们使用昂贵的数据动词（关键发现 #2）、小消息或错误处理行为（关键发现 #3）来耗尽 NIC PU；我们使用密集型控制动词（关键发现 #1）和大范围访问的数据动词来耗尽不同类型的 RNIC 缓存。我们改变某些合成工作负载的参数（例如连接类型）以使其更具包容性。总之，Husky 包括 52 个攻击者合成工作负载（6 个用于 NIC 带宽，4 个用于 PCIe 带宽，14 个用于 NIC PU，28 个用于 NIC 缓存）和 20 个合成受害者工作负载。许多攻击者工作负载无法直接用现有的 RDMA 流量引擎生成。因此，我们扩展了 Collie 33 的流量引擎------据我们所知最灵活的引擎------来生成这些合成 RDMA 流量，包括灵活的控制动词工作负载和错误处理工作负载。
Husky 的框架还可以轻松允许运行真实应用作为额外的受害者工作负载。Husky 目前包含两个真实应用，包括 OSU 基准测试 54 和基于 eRPC 的 Masstree 键值存储 27,40。OSU 基准测试包含 allreduce 和 allgather 等工作负载。请注意，我们可以将任何 RDMA 应用集成到 Husky 中。我们穷尽测试了测试套件中所有（受害者、攻击者）工作负载对。
一个关键问题是如何定义性能隔离的违反。我们对违反的定义取决于具体的隔离解决方案。Husky 使用用户指定的谓词来计算启用隔离时的预期性能结果。Husky 将实际性能与预期性能进行比较以识别违反。例如，大多数现有性能隔离解决方案仅提供带宽保证。因此，这些隔离解决方案的预期性能是保证带宽 Bg。我们假设应用在单独运行时可以消耗 Ba 的带宽。在任何攻击者工作负载下，该应用的带宽应至少为 (1−α)min(Ba,Bg)，其中 α 是容忍度。较低的 α 意味着更严格的隔离。我们用一个例子来说明这个定义如何运作：让我们假设攻击者和受害者被配置为共享同一个 100 Gbps 网络，我们将 α 设为 25%。如果受害者单独运行时可以达到 60 Gbps，那么在攻击者的工作负载下，它应该至少能够达到 (1−25%)min(60,50) = 37.5 Gbps。如果受害者单独运行时只能达到 10 Gbps，其消耗的带宽不应低于 (1−25%)min(10,50) = 7.5 Gbps。在实践中，我们发现所有针对商用 RNIC 的现有性能隔离解决方案都是带宽保证或可以转化为带宽保证。我们在第 5 节中使用此定义来判断性能隔离违反，并将 α 设为 25%。
5 评估
我们使用 NVIDIA 测试平台来评估现有的 RDMA 性能隔离解决方案。测试平台中有两台服务器，每台服务器配备一个 100 Gbps NVIDIA ConnectX-5 RNIC。服务器配备 Intel Xeon Gold 5215 CPU，RNIC 通过 PCIe 3.0 x16 连接到服务器。RNIC 连接到一个 100 Gbps NVIDIA 交换机。我们使用 Ubuntu 20.04，内核版本为 5.11。对于 NVIDIA 网卡，内核驱动程序和动词库均来自 5.4-OFED。固件版本为 16.31.1014。我们还在 NVIDIA ConnectX-6 RNIC 上进行了所有实验，结果类似。
我们评估了 RNIC 供应商和先前工作提供的 3 种不同隔离解决方案：(1) NVIDIA 独立硬件流量类别（HW TC）。云运营商可以为不同租户设置独立的 TC，从而分离 RNIC 带宽和数据包缓冲区 47 以强制执行性能隔离。现代 RNIC 通常只有 8 个流量类别。这意味着当我们想在物理服务器中共置超过 8 个租户时，无法使用 HW TC。(2) NVIDIA SR-IOV。尽管 SR-IOV 技术是为硬件虚拟化而设计的，但它为不同租户提供了具有某些分离资源的独立虚拟功能，实际上实现了一定程度的性能隔离 45。(3) Justitia，一种基于软件的性能隔离解决方案 71。Justitia 在 RDMA 用户空间库中实现数据动词速率限制和步调控制以强制执行性能隔离。这意味着 Justitia 没有安全性：恶意应用可以轻松绕过用户空间库。尽管 Justitia 的软件架构不针对多租户公共云环境，我们仍然使用 Husky 来评估其隔离策略的效果（例如其基于令牌的算法）。我们还评估了上述解决方案的所有可能组合²。不幸的是，尽管我们有配备 Chelsio T62100-LP-CR 和 Intel E810 网卡的测试平台，但我们未能启用它们的基于硬件的隔离机制。Justitia 也不支持 Chelsio 或 Intel 驱动程序。因此，我们无法在 Chelsio 或 Intel 网卡上进行相同的评估。³
²我们不测试 Justitia 与 SR-IOV 的组合，因为 Justitia 只隔离通过同一设备的流量。当启用 SR-IOV 时，租户使用不同的设备（即 VF），Justitia 在该场景下不起作用。
³我们联系了网卡供应商，并与他们的专家进行了多轮对话。然而，我们仍然未能为这两种网卡启用任何 RDMA 硬件隔离解决方案。此外，我们不知道有任何先前工作可以建立这样的 RDMA 隔离。
5.1 测试现有性能隔离解决方案
基于动词类型和耗尽的资源，我们将 Husky 生成的工作负载分为 6 组。我们将 RC 的错误处理与 UD 和 UC 区分开来，因为它们导致 RNIC PU 的不同行为，并且我们观察到某些隔离解决方案（例如 SR-IOV）对这些 PU 行为提供了不同程度的隔离。
我们首先看看 NVIDIA 提供的基于硬件的隔离机制。对于 NVIDIA SR-IOV，我们启用两个虚拟功能（VF），并为受害者租户和攻击者租户各分配一个 VF。我们还启用基于 VF 的速率限制器，将每个租户的最大 TX 带宽限制为 50 Gbps，这是公共多租户环境中典型的公平共享设置。鉴于此配置，我们将 NVIDIA SR-IOV 的隔离违反定义为攻击者将受害者消耗的带宽（以每秒比特计）降低到低于 (1−α)min(50,Ba)，其中 α 为 25%，Ba 是受害者无攻击时的带宽。对于 NVIDIA HW TC，我们为每个租户分配一个专用 TC。例如，受害者独占使用 TC 0，攻击者独占使用 TC 3。我们将 TC 0 和 TC 3 配置为平等共享 RNIC 带宽和 NIC 缓冲区（存储数据包，与缓存不同）。因此，NVIDIA HW TC 的违反定义与 NVIDIA SR-IOV 相同。
表 3 的前三行显示了 SR-IOV、HW TC 以及它们组合提供的隔离效果。不幸的是，我们发现 SR-IOV 和 HW TC 都未能为 RNIC 的微架构资源提供足够的隔离。例如，通过控制动词或数据动词耗尽 RNIC 缓存，Husky 可以成功影响共处的受害者应用，即使同时启用了 SR-IOV 和 HW TC。关键原因是 SR-IOV 和 HW TC 只隔离架构资源（例如链路带宽），而不限制单个租户的缓存使用。因此，Husky 能够使用耗尽 RNIC 缓存（例如 MTT/MPT 缓存）的攻击者工作负载。其他应用将遭受严重的缓存未命中，从而导致性能下降。此外，我们发现尽管 SR-IOV 主要针对虚拟化，但它确实强制执行了一些隔离，特别是对于 RNIC PU。如果没有启用性能隔离机制，RC RNR 错误处理可能导致 RNIC PU 暂停甚至挂起共处应用。使用 SR-IOV，RC RNR 错误不会影响在其他 VF 上运行的租户。然而，UD 和 UC 类似的 RNR 异常处理过程仍然违反了 SR-IOV 的隔离。由于 RNIC 的黑盒特性，我们不知道这种差异的根本原因。我们最好的猜测是 RNIC 的某些 PU 部分（例如处理 RC RNR 的部分）被不同的 VF 隔离，而其他部分隔离不够好。这些基于硬件的解决方案也无法很好地隔离 PCIe 带宽。我们观察到攻击者可以消耗大量 PCIe 带宽，减少受害者的可用带宽。
然后我们评估基于软件的解决方案 Justitia。Justitia 不是为公共云设计的，需要租户配合（例如使用修改后的 RDMA 库）。Husky 当然可以通过绕过修改后的库来打破其隔离，但这会违背测试 Justitia 的目的。因此，我们要求 Husky 的所有流量（包括受害者和攻击者）都通过 Justitia 的修改驱动程序，并由 Justitia 进行步调控制。此外，Justitia 在最新驱动程序（即 mlx5）上仅支持有限类型的数据动词，因此我们将应用限制为仅使用 Justitia 支持的操作码。Justitia 旨在为每个租户提供 NIC 资源的公平份额。我们只设置两个租户，因此我们将 Justitia 的违反简单定义为受害者的带宽低于 (1−α)min(Ba,50)，类似于 SR-IOV 的定义。我们还测试了 Justitia 和 HW TC 的组合。
如表 3 所示，Justitia 确实提供了一些 PU 隔离，但程度有限。例如，Justitia 将 RNIC 的请求速率（即执行吞吐量）纳入其隔离考虑。因此，它使用步调控制器来控制每个租户的请求速率，并成功阻止单个租户发布大量请求来耗尽 PU。然而，当攻击者持续发布触发 RNIC 错误处理的请求时，其隔离就被违反了。原因是这些错误由 RNIC 检测和处理，这超出了 Justitia 的控制范围。此外，Justitia 没有考虑缓存和 PCIe。因此，攻击者租户仍然可以耗尽 RNIC 缓存和 PCIe 带宽，导致其他租户遭受过多的缓存未命中或低可用 PCIe 带宽。
值得注意的是，这些解决方案已经为架构资源（例如 NIC 带宽）提供了或多或少可容忍的隔离。Husky 包含一组只争用 NIC 带宽的工作负载，启用这些解决方案时，我们在这些工作负载上没有看到此类违反。然而，忽略微架构资源使得这些解决方案不足以用于真正的公共云部署。
5.2 对真实应用的影响
接下来，我们在更大的测试平台上进行实验，研究在使用最先进的性能隔离解决方案时，微架构资源耗尽如何影响真实应用工作负载。我们使用基于 RDMA 的 MPI 实现 55 上的 allreduce 工作负载 54 和基于 eRPC 的 Masstree（键值存储）27,40 作为两个真实受害者应用。我们的测试平台由四台物理服务器组成。每台服务器配备一个 100 Gbps NVIDIA ConnectX-5 RNIC。其他设置与第 5.1 节相同。受害者应用在所有四台服务器上运行其虚拟机。攻击者租户控制两个虚拟机，每个虚拟机位于不同的服务器上。我们以这种方式设置测试平台来模拟真实的多租户环境，因为攻击者可能没有虚拟机与所有受害者的虚拟机共处。然而，我们的结果表明，在受害者虚拟机的一个子集上违反性能隔离已经足以大幅降低真实分布式应用的整体端到端性能。
对于保护机制，我们为集体通信应用启用 SR-IOV + HW TC 或 Justitia + HW TC 来提供隔离。对于基于 eRPC 的 Masstree，我们只启用 SR-IOV + HW TC。这是因为 Justitia 仅在最新的 NVIDIA 驱动程序上支持高性能 RDMA WRITE，但基于 eRPC 的 Masstree 利用 UD SEND/RECV 进行通信。
我们使用 Husky 测试套件中的四种类型的攻击者来证明我们的结果：(1) BW 攻击是基线。我们使用标准 Perftest 56 ib_write_bw 来建立一个 hungry 带宽应用。它使用 16 个 RC QP，每个 QP 保持 128 个在途 1 MB WRITE 请求来饱和链路带宽（启用速率限制器时消耗约 50 Gbps）。BW 攻击不针对任何微架构资源。(2) PCIe 攻击耗尽 PCIe TX 带宽。它在 6 个核心上运行 36 个 RC QP，并保持 128 个在途 257 B WRITE 请求。它也消耗几乎 50 Gbps 链路带宽（低于 20 Mrps），但导致超过 73 Gbps 的 PCIe TX 带宽消耗。这仅留下约 50 Gbps 可用 PCIe TX 带宽（即低于 50 Gbps 可用网络带宽）给受害者。(3) 缓存攻击耗尽 RNIC 缓存。它在 6 个核心上运行 1536 个 RC QP，使用 12288 个 MR，每个 QP 仅保持单个 256 B 在途请求。此攻击者导致严重的缓存未命中，仅使用低于 7 Gbps 链路带宽（即 3 Mrps）。(4) PU 攻击暂停 RNIC PU。它在单个核心上运行 1 个 UC QP，并保持 128 个在途 SEND/RECV 请求。其接收方不发布任何接收请求，因此 RNIC 必须处理许多接收未就绪异常。它消耗低于 0.5 Gbps 和低于 0.5 Mrps。
我们首先测试基于 RDMA 的 allreduce 工作负载。Allreduce 是一种广泛用于分布式深度学习训练的集体通信操作。它聚合所有工作进程上的向量并将结果传播回所有工作进程。我们在每台主机上设置 2 个工作进程（共 8 个）来运行 allreduce。Allreduce 缓冲区大小设为 1 MB。我们持续运行 allreduce 并记录执行速率（每秒 allreduce 操作数）。没有任何隔离机制和干扰的原始速率显示为图中最左侧的条形。无攻击条形表示启用这些隔离解决方案的效果。启用 Justitia 时，allreduce 速率下降 38.5%。一个可能的原因是 Justitia 使用垫片层（步调控制器）来执行发送方准入控制，与基于硬件的解决方案相比引入了额外的性能开销。由于 allreduce 工作负载仅使用不到一半 NIC 带宽（23 Gbps），其在攻击下的性能应至少为 (1−α)Pa，其中 α 为 25%，Pa 是其没有任何攻击时的性能。然后我们可以根据受害者应消耗的带宽计算每个隔离解决方案的 allreduce 速率违反阈值。
Allreduce 的结果如图 8 所示。水平红线显示违反阈值。红线以下的条形表示隔离违反。使用 Justitia + HW TC 的应用的 Pa 比使用 SR-IOV + HW TC 低 38.5%。这意味着 Justitia + HW TC 的违反阈值也低 38.5%。我们首先观察到 BW 攻击仅对 SR-IOV + HW TC 设置造成可忽略的性能下降。Justitia + HW TC 也在容忍范围内实现了带宽隔离目标。然后我们观察到所有 PCIe、缓存和 PU 攻击都成功违反了 Justitia + HW TC 或 SR-IOV + HW TC 提供的隔离。例如，PCIe 攻击可以使 allreduce 应用的性能在 SR-IOV + HW TC 下下降 27.3%，在 Justitia + HW TC 下下降 42.1%。缓存攻击的影响更为显著。Allreduce 工作负载的性能在 Justitia + HW TC 下下降超过一半（71.3%），在 SR-IOV + HW TC 下几乎下降一半。我们观察到 PU 攻击是最强大的。它可以通过耗尽 RNIC PU 直接暂停 allreduce 应用。
我们使用同一组攻击者来测试基于 eRPC 的 Masstree。我们使用基于 eRPC 的 Masstree 的默认设置（例如密钥大小和线程数）。我们在一台物理服务器上设置键值服务器，在三个不同的物理服务器上各设置一个客户端。我们将一个攻击者虚拟机与键值服务器共处，另一个攻击者虚拟机与其中一个客户端共处。我们从所有客户端收集执行速率（以每秒 GET 请求数计）和延迟。Masstree 服务器仅使用 14 Mrps 和低于 20 Gbps，因此我们将隔离违反定义为与 allreduce 的违反相同。图 9 和图 10 显示了 GET 速率和延迟结果。SR-IOV + HW TC 或多或少在容忍范围内实现了 BW 隔离目标。
我们发现所有微架构资源耗尽攻击都成功违反了与攻击者虚拟机共处的客户端的隔离。与 allreduce 工作负载类似，PU 攻击者暂停了整个键值存储系统。更糟糕的是，它甚至暂停了不与攻击者虚拟机共处的客户端。这是因为我们暂停了键值服务器。另一个观察是基于 eRPC 的 Masstree 的性能受到缓存耗尽攻击的损害，但程度非常有限。一个可能的原因是 eRPC 利用 UD 传输。UD QP 不需要像 RC QP 那样多的连接元数据，因此对 RNIC 内部缓存未命中不太敏感。此外，我们发现 Masstree 对 PCIe 耗尽更敏感。这可能是由于其请求大小较小。根据我们的关键发现 #4，相对较小大小的请求会导致更多额外的 PCIe TX 带宽消耗。
我们从真实应用结果中得出几个高层收获：
收获 #1：针对微架构资源使违反性能隔离变得容易。 如果我们将 RNIC 视为黑盒，很难打破性能隔离。BW 攻击针对带宽资源，我们观察到所有现有解决方案都提供了良好的保护。然而，一旦我们了解 RNIC 如何工作的更多细节（例如潜在的微架构资源），打破隔离就变得简单。我们的攻击非常高效。例如，缓存攻击仅需 7 Gbps 和 3 Mrps。PU 攻击以更低的带宽和请求速率暂停受害者。请注意，这些攻击仅针对公开披露的微架构组件。
收获 #2：应用对资源争用的敏感度不同。 即使对于同一攻击，应用的端到端性能下降也可能非常不同。Allreduce 应用对缓存耗尽更敏感，而 Masstree 对 PCIe 耗尽更脆弱。
收获 #3：分布式应用需要在每台单个服务器上实现性能隔离。 对于这两个应用，攻击者只有两个虚拟机，但为什么即使应用跨四台机器运行，应用级性能也会大幅下降？许多现代分布式系统的性能通常受系统中最慢的几个工作进程限制。例如，在 allreduce 中，每次迭代都需要所有工作进程的同步。因此，我们对一个或两个工作进程的攻击可以减慢整个 allreduce 过程。
5.3 现有解决方案分析
我们的评估表明，所有现有方法都未能提供 RDMA 性能隔离。我们现在分析这些解决方案的根本限制以及我们可能实现的一些潜在改进。
SR-IOV 和独立 HW TC。 这些基于硬件的解决方案已经提供了一些硬件资源隔离（例如硬件队列和网卡上的数据包缓冲区）。理论上，RNIC 供应商应该能够将这些解决方案纳入更多硬件隔离功能。例如，静态分离不同 VF 的 NIC PU 或分区 NIC 缓存可以帮助为 SR-IOV 构建更好的隔离机制。然而，这些硬件修改并非微不足道，很难应用于现有硬件。RNIC 供应商通常与其新硬件产品一起发布这些新功能。因此，云提供商无法在现有硬件中使用这些功能。
Justitia。 Justitia 提供修改后的用户空间库，并使用发送方准入控制来强制执行所有租户的带宽和执行速率的公平共享。Justitia 不适用于多租户云，因为其策略不可强制执行：恶意应用可以轻松绕过修改后的用户库。撇开安全方面不谈，值得问的是像 Justitia 这样的纯软件解决方案在理论上是否可以支持 RDMA 性能隔离。我们对这个问题没有直接答案，我们相信这是一个有趣的未来研究方向。我们认为这可能相当困难，原因如下。首先，在没有硬件支持的情况下，跟踪和控制租户占用了多少缓存具有挑战性。其次，为动词建立定量资源消耗模型具有挑战性。最后，错误处理深度集成到 RDMA NIC 硬件中，对软件不透明。
6 设计指南
我们的结果表明，不幸的是，没有现有的 RNIC 性能隔离解决方案是足够的。我们基于关键发现分析现有隔离解决方案的失败，并为潜在的未来的 RDMA 性能隔离工作提出几个设计指南。这些指南也可能有助于 RDMA 应用开发人员在多租户环境下编写更好的 RDMA 应用。
需要硬件支持来实现隔离。 像 Justitia 71 这样的软件方法有一个共同的问题。它们只监控架构级指标，例如延迟、带宽和请求速率。它们无法检测微架构资源（例如缓存）中的争用，更不用说管理和公平共享这些资源了。我们相信未来的性能隔离解决方案将不得不利用硬件支持，类似于现代虚拟机监控程序如何使用 Intel Resource Director Technology (RDT) 来监控和管理对最后一级缓存和内存的访问。NVIDIA RNIC 暴露了几个有用的硬件计数器，但它们仍然不足。例如，我们只能观察缓存未命中，但无法管理缓存访问或为不同租户拆分缓存。
需要一层间接层。 RDMA 意味着数据动词的内核旁路。这实现了低延迟和降低的 CPU 开销。那么应该在哪里强制执行性能隔离呢？我们相信未来的性能隔离解决方案将需要在 NIC 或软件中设置一层间接层。将执行点放在用户态 RDMA 库中（如 Justitia）不起作用，因为它缺乏安全性。相反，软件间接层可以采用类似微内核的设计，一组核心在单独的保护域 43 中运行隔离逻辑。RDMA 性能隔离应该在这样的中央控制器中强制执行，该控制器接管控制动词和数据动词。
RDMA 应用的程序员、编译器和库支持。 在未来的性能隔离解决方案发明之后，应用可能也需要修改。如果未来的性能隔离解决方案需要严格分区微架构资源，这意味着每个应用有有限的微架构资源可用，并可能导致性能大幅降低。应用使用的微架构资源量也可能有所不同（取决于同一服务器上有多少其他租户或其他配置）。构建高性能 RDMA 应用将需要程序员、编译器和应用库付出额外的努力，以高效使用这些有限的资源。对于 CPU 缓存，这些努力发生在二十年前的研究界 35,36,42。
7 讨论
RDMA 性能隔离被破坏的影响。 我们的评估表明，恶意租户可能导致其他租户遭受严重的性能下降甚至卡住。此外，被破坏的性能隔离为恶意用户进行侧信道攻击暴露了漏洞。由于租户可以影响同一主机上其他租户的性能，它可以建立侧信道来泄露受害者节点的访问模式，或通过以某种模式影响主机性能来传递信息 65。因此，RDMA 性能隔离是安全 RDMA 公共云的关键特性。
云提供商今天应该使用什么 RDMA 性能隔离解决方案？ 一个好消息是，我们不知道有任何云提供商目前使用商用 RNIC 提供具有分区主机资源的 RDMA 功能虚拟机。要租用支持 RDMA 的虚拟机，客户必须租用整台物理机。这意味着目前我们根本不需要 RNIC 性能隔离解决方案，因为 RNIC 只运行单个租户的流量。要推进 RNIC 的多租户使用，我们相信性能隔离仍然是一个主要障碍，在成熟的性能隔离解决方案准备好之前不应启用多租户，该解决方案至少应能通过我们的测试套件。
对其他内核旁路主机网络架构的通用性。 我们的测试套件设计基于动词接口，这是 RDMA 特有的。然而，我们相信我们的方法应该可以推广到发现其他内核旁路架构中的性能隔离违反，例如 DPDK 13、1RMA 64，因为这些实现在设计的 DMA 部分通常需要类似 RDMA 的机制。当今的行业趋势是将功能卸载到硬件加速器。例如，RDMA 正在将拥塞控制和可靠消息传递卸载到硬件中。硬件中的微架构资源对于交付这些卸载功能至关重要。关注这些微架构资源以实现性能隔离将变得越来越重要。
8 相关工作
RNIC 中的微架构资源。 RNIC 微架构资源的存在在网络界是众所周知的，许多研究专注于如何设计 RDMA 应用来规避由于这些资源导致的某些 RNIC 性能异常。例如，HERD 28、FaSST 30 和 eRPC 27 避免使用 RDMA 可靠连接来缓解 QP 上下文缓存未命中以获得更好的可扩展性。ScaleRPC 5 和 Flock 50 以时分复用方式多路复用可靠连接来缓解可扩展性问题。Kalia 等人 29 研究了 RNIC 的 PCIe 行为，并提供了编写高效 RDMA 程序的指南。不幸的是，这些工作只专注于优化应用以充分利用 RNIC 中的有限资源。然而，公共云提供商无法控制第三方租户的应用。Collie 33 对 RDMA 性能异常进行了系统搜索，这些异常主要是由于过度订阅的微架构资源。然而，由于 Collie 只关注第一方流量，它只是基于正常操作构建搜索空间。因此，它只考虑正常的数据动词，未能发现与其他类型行为相关的发现。例如，第 3 节中的关键发现 #1、#2 和 #3 根本不在 Collie 的搜索空间范围内，因为 Collie 没有考虑控制动词、错误处理和昂贵的原子动词。总之，先前的工作更多从应用开发人员的角度出发。我们的工作是从公共云提供商的角度进行互补：这些微架构资源如何影响性能隔离。这要求我们对微架构资源有意识，并审视所有类型的 RDMA 行为，包括控制动词和错误处理，因为我们需要处理行为不端甚至恶意的租户。
其他 NIC 性能隔离解决方案。 PicNIC 34 为 NIC 上的数据包处理和带宽提供隔离。这允许延迟受限的工作负载不受带宽受限工作负载的影响。FairNIC 15 隔离基于 SoC 的 SmartNIC 中的资源。与它们相比，我们的工作专注于 NIC 上与 RDMA 相关的资源。
其他上下文中的性能隔离。 性能隔离问题不仅限于 NIC。其他服务器硬件组件也有这个问题，并且它们已经有相应的解决方案。存在几种用于 CPU 缓存 11,20 和内存带宽 22 的分区技术。网络结构中的网络带宽也是一个需要隔离的关键资源 1,3,4,6,16,24,25,37,58--60,62,68，以及交换机处理流水线 67。
9 结论
RDMA 是一种有前途的网络技术，可在数据中心网络中实现低延迟和高 CPU 效率。要在多租户环境中启用 RDMA，性能隔离是一个重要属性，而 RDMA NIC（RNIC）由于微架构资源（例如 RNIC 缓存、处理单元）的存在带来了新的挑战。我们提出了一个 RNIC 操作模型，说明这些资源如何被不同的 RDMA 操作使用。利用该模型，我们创建了 Husky，第一个评估 RNIC 性能隔离解决方案的测试套件。我们的结果表明，没有任何现有 RNIC 性能隔离解决方案能够对试图耗尽这些微架构资源的工作负载提供足够的隔离。我们的发现得到了最大的 RDMA NIC 供应商之一的确认和复现。我们相信，构建可用的 RNIC 性能隔离解决方案将是一场持久战。
致谢
我们感谢 Chelsio 和 Intel 的技术支持。我们特别感谢 NVIDIA，他们及时提供了富有洞察力的反馈，包括我们发现的根本原因和相应的解决方案。我们感谢我们的导师 Brent Stephens 和其他匿名审稿人的深刻反馈。我们的工作部分得到 Adobe、Amazon、Meta 和 IBM 的捐赠支持。
参考文献
1 Sebastian Angel, Hitesh Ballani, Thomas Karagiannis, Greg O'Shea, and Eno Thereska. End-to-End Performance Isolation through Virtual Datacenters. In OSDI, 2014.
2 Infiniband Trade Association. Rocev2, 2014.
3 Hitesh Ballani, Paolo Costa, Thomas Karagiannis, and Ant Rowstron. Towards Predictable Datacenter Networks. In SIGCOMM, 2011.
4 Hitesh Ballani, Keon Jang, Thomas Karagiannis, Changhoon Kim, Dinan Gunawardena, and Greg O'Shea. Chatty Tenants and the Cloud Network Sharing Problem. In NSDI, 2013.
5 Youmin Chen, Youyou Lu, and Jiwu Shu. Scalable RDMA RPC on Reliable Connection with Efficient Resource Sharing. In EuroSys, 2019.
6 Mosharaf Chowdhury, Zhenhua Liu, Ali Ghodsi, and Ion Stoica. HUG: Multi-Resource Fairness for Correlated and Elastic Demands. In NSDI, 2016.
7 The Global Cloud Computing Market Size. https://www.yahoo.com/now/global-cloud-computing-market-size-081600295.html, 2021.
8 Chelsio Communications. 100g network performance for illumos, 2018.
9 Aleksandar Dragojevic, Dushyanth Narayanan, Miguel Castro, and Orion Hodson. FaRM: Fast Remote Memory. In NSDI, 2014.
10 Aleksandar Dragojevic, Dushyanth Narayanan, Edmund B. Nightingale, Matthew Renzelmann, Alex Shamis, Anirudh Badam, and Miguel Castro. No Compromises: Distributed Transactions with Consistency, Availability, and Performance. In SOSP, 2015.
11 Nosayba El-Sayed, Anurag Mukkara, Po-An Tsai, Harshad Kasture, Xiaosong Ma, and Daniel Sanchez. KPart: A Hybrid Cache Partitioning-Sharing Technique for Commodity Multicores. In HPCA, 2018.
12 Alexandra Fedorova, Margo Seltzer, and Michael D Smith. Improving performance isolation on chip multiprocessors via an operating system scheduler. In 16th International Conference on Parallel Architecture and Compilation Techniques (PACT 2007), pages 25--38. IEEE, 2007.
13 Linux Foundation. Data plane development kit (DPDK). http://www.dpdk.org, 2015.
14 Yixiao Gao, Qiang Li, Lingbo Tang, Yongqing Xi, Pengcheng Zhang, Wenwen Peng, Bo Li, Yaohui Wu, Shaozong Liu, Lei Yan, Fei Feng, Yan Zhuang, Fan Liu, Pan Liu, Xingkui Liu, Zhongjie Wu, Junping Wu, Zheng Cao, Chen Tian, Jinbo Wu, Jiaji Zhu, Haiyong Wang, Dennis Cai, and Jiesheng Wu. When cloud storage meets RDMA. In NSDI 21, 2021.
15 Stewart Grant, Anil Yelam, Maxwell Bland, and Alex C. Snoeren. SmartNIC Performance Isolation with FairNIC: Programmable Networking for the Cloud. In SIGCOMM, 2020.
16 Chuanxiong Guo, Guohan Lu, Helen J. Wang, Shuang Yang, Chao Kong, Peng Sun, Wenfei Wu, and Yongguang Zhang. SecondNet: A Data Center Network Virtualization Architecture with Bandwidth Guarantees. In CoNEXT, 2010.
17 Chuanxiong Guo, Haitao Wu, Zhong Deng, Gaurav Soni, Jianxi Ye, Jitu Padhye, and Marina Lipshteyn. RDMA over Commodity Ethernet at Scale. In SIGCOMM, 2016.
18 Diwaker Gupta, Ludmila Cherkasova, Rob Gardner, and Amin Vahdat. Enforcing performance isolation across virtual machines in xen. In ACM/IFIP/USENIX International Conference on Distributed Systems Platforms and Open Distributed Processing, pages 342--362. Springer, 2006.
19 Zhiqiang He, Dongyang Wang, Binzhang Fu, Kun Tan, Bei Hua, Zhi-Li Zhang, and Kai Zheng. MasQ: RDMA for Virtual Private Cloud. In SIGCOMM, 2020.
20 Andrew Herdrich, Edwin Verplanke, Priya Autee, Ramesh Illikkal, Chris Gianos, Ronak Singhal, and Ravi Iyer. Cache QoS: From Concept to Reality in the Intel Xeon Processor E5-2600 v3 Product Family. In HPCA, 2016.
21 Jeff Hilland. RDMA Protocol Verbs Specification. Technical report, Internet Engineering Task Force, 2003.
22 Derek R. Hower, Harold W. Cain, and Carl A. Waldspurger. PABST: Proportionally Allocated Bandwidth at the Source and Target. In HPCA, 2017.
23 IEEE. 802.3-2018 - ieee standard for ethernet. https://ieeexplore.ieee.org/document/8457469.
24 Keon Jang, Justine Sherry, Hitesh Ballani, and Toby Moncaster. Silo: Predictable Message Latency in the Cloud. In SIGCOMM, 2015.
25 Vimalkumar Jeyakumar, Mohammad Alizadeh, David Mazières, Balaji Prabhakar, Albert Greenberg, and Changhoon Kim. EyeQ: Practical Network Performance Isolation at the Edge. In NSDI, 2013.
26 Yimin Jiang, Yibo Zhu, Chang Lan, Bairen Yi, Yong Cui, and Chuanxiong Guo. A Unified Architecture for Accelerating Distributed DNN Training in Heterogeneous GPU/CPU Clusters. In OSDI, 2020.
27 Anuj Kalia, Michael Kaminsky, and David Andersen. Datacenter RPCs can be General and Fast. In NSDI, 2019.
28 Anuj Kalia, Michael Kaminsky, and David G. Andersen. Using RDMA Efficiently for Key-Value Services. In SIGCOMM, 2014.
29 Anuj Kalia, Michael Kaminsky, and David G. Andersen. Design Guidelines for High Performance RDMA Systems. In USENIX ATC, 2016.
30 Anuj Kalia, Michael Kaminsky, and David G. Andersen. FaSST: Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Datagram RPCs. In OSDI, 2016.
31 Daehyeok Kim, Tianlong Yu, Hongqiang Harry Liu, Yibo Zhu, Jitu Padhye, Shachar Raindel, Chuanxiong Guo, Vyas Sekar, and Srinivasan Seshan. FreeFlow: Software-based Virtual RDMA Networking for Containerized Clouds. In NSDI, 2019.
32 Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, and Yuval Yarom. Spectre Attacks: Exploiting Speculative Execution. In IEEE S&P, 2019.
33 Xinhao Kong, Yibo Zhu, Huaping Zhou, Zhuo Jiang, Jianxi Ye, Chuanxiong Guo, and Danyang Zhuo. Collie: Finding Performance Anomalies in RDMA Subsystems. In NSDI, 2022.
34 Praveen Kumar, Nandita Dukkipati, Nathan Lewis, Yi Cui, Yaogong Wang, Chonggang Li, Valas Valancius, Jake Adriaens, Steve Gribble, Nate Foster, and Amin Vahdat. PicNIC: Predictable Virtualized NIC. In SIGCOMM, 2019.
35 Monica D. Lam, Edward E. Rothberg, and Michael E. Wolf. The Cache Performance and Optimizations of Blocked Algorithms. ASPLOS IV, 1991.
36 A.R. Lebeck and D.A. Wood. Cache Profiling and the SPEC Benchmarks: a Case Study. Computer, 27(10):15--26, 1994.
37 Jeongkeun Lee, Yoshio Turner, Myungjin Lee, Lucian Popa, Sujata Banerjee, Joon-Myung Kang, and Puneet Sharma. Application-Driven Bandwidth Guarantees in Datacenters. In SIGCOMM, 2014.
38 Yuliang Li, Rui Miao, Hongqiang Harry Liu, Yan Zhuang, Fei Feng, Lingbo Tang, Zheng Cao, Ming Zhang, Frank Kelly, Mohammad Alizadeh, and Minlan Yu. HPCC: High Precision Congestion Control. In SIGCOMM, 2019.
39 Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg. Meltdown: Reading Kernel Memory from User Space. In USENIX Security, 2018.
40 Yandong Mao, Eddie Kohler, and Robert Tappan Morris. Cache Craftiness for Fast Multicore Key-Value Storage. In EuroSys, 2012.
41 Artemiy Margaritov, Siddharth Gupta, Rekai Gonzalez-Alberquilla, and Boris Grot. Stretch: Balancing QoS and Throughput for Colocated Server Workloads on SMT Cores. In HPCA, 2019.
42 M. Martonosi, A. Gupta, and T.E. Anderson. Tuning Memory Performance of Sequential and Parallel Programs. Computer, 28(4):32--40, 1995.
43 Michael Marty, Marc de Kruijf, Jacob Adriaens, Christopher Alfeld, Sean Bauer, Carlo Contavalli, Michael Dalton, Nandita Dukkipati, William C. Evans, Steve Gribble, Nicholas Kidd, Roman Kononov, Gautam Kumar, Carl Mauer, Emily Musick, Lena Olson, Erik Rubow, Michael Ryan, Kevin Springborn, Paul Turner, Valas Valancius, Xi Wang, and Amin Vahdat. Snap: A Microkernel Approach to Host Networking. In SOSP, 2019.
44 Mellanox. Mellanox neo-host network adapter management software. https://support.mellanox.com/s/productdetails/a2v50000000N2OlAAK/mellanox-neohost.
45 Mellanox Single Root IO Virtualization (SR-IOV). https://docs.nvidia.com/networking/pages/viewpage.action?pageId=12013542.
46 Mellanox. Proprietary mellanox adapter diagnostics counters. https://docs.nvidia.com/networking/m/view-rendered-page.action?abstractPageId=12005244.
47 Mellanox Quality of Service (QoS). https://docs.mellanox.com/pages/viewpage.action?pageId=19811934, 2018.
48 Mellanox Adapters Programmer's Reference Manual. https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf, 2021.
49 Radhika Mittal, Alexander Shpiner, Aurojit Panda, Eitan Zahavi, Arvind Krishnamurthy, Sylvia Ratnasamy, and Scott Shenker. Revisiting Network Support for RDMA. In SIGCOMM, 2018.
50 Sumit Kumar Monga, Sanidhya Kashyap, and Changwoo Min. Birds of a Feather Flock Together: Scaling RDMA RPCs with Flock. In SOSP, 2021.
51 Dheevatsa Mudigere, Yuchen Hao, Jianyu Huang, Zhihao Jia, Andrew Tulloch, Srinivas Sridharan, Xing Liu, Mustafa Ozdal, Jade Nie, Jongsoo Park, Liang Luo, Jie Amy Yang, Leon Gao, Dmytro Ivchenko, Aarti Basant, Yuxi Hu, Jiyan Yang, Ehsan K. Ardestani, Xiaodong Wang, Rakesh Komuravelli, Ching-Hsiang Chu, Serhat Yilmaz, Huayu Li, Jiyuan Qian, Zhuobo Feng, Yinbin Ma, Junjie Yang, Ellie Wen, Hong Li, Lin Yang, Chonglin Sun, Whitney Zhao, Dimitry Melts, Krishna Dhulipala, KR Kishore, Tyler Graf, Assaf Eisenman, Kiran Kumar Matam, Adi Gangidi, Guoqiang Jerry Chen, Manoj Krishnan, Avinash Nayak, Krishnakumar Nair, Bharath Muthiah, Mahmoud khorashadi, Pallab Bhattacharya, Petr Lapukhov, Maxim Naumov, Ajit Mathews, Lin Qiao, Mikhail Smelyanskiy, Bill Jia, and Vijay Rao. Software-Hardware Co-design for Fast and Scalable Training of Deep Learning Recommendation Models, 2021.
52 Rolf Neugebauer, Gianni Antichi, José Fernando Zazo, Yury Audzevich, Sergio López-Buedo, and Andrew W. Moore. Understanding PCIe Performance for End Host Networking. In SIGCOMM, 2018.
53 Stanko Novakovic, Yizhou Shan, Aasheesh Kolli, Michael Cui, Yiying Zhang, Haggai Eran, Boris Pismenny, Liran Liss, Michael Wei, Dan Tsafrir, and Marcos Aguilera. Storm: A Fast Transactional Dataplane for Remote Data Structures. In SYSTOR, 2019.
54 OSU benchmarks. https://mvapich.cse.ohio-state.edu/benchmarks/, 2021.
55 Dhabaleswar Kumar Panda, Hari Subramoni, Ching-Hsiang Chu, and Mohammadreza Bayatpour. The MVAPICH project: Transforming Research into High-Performance MPI Library for HPC Community. Journal of Computational Science, 2021.
56 OFED perftest. https://github.com/linux-rdma/perftest, 2021.
57 Jonas Pfefferle, Patrick Stuedi, Animesh Trivedi, Bernard Metzler, Ionnis Koltsidas, and Thomas R. Gross. A Hybrid I/O Virtualization Framework for RDMA-Capable Network Interfaces. In VEE, 2015.
58 Lucian Popa, Gautam Kumar, Mosharaf Chowdhury, Arvind Krishnamurthy, Sylvia Ratnasamy, and Ion Stoica. FairCloud: Sharing the Network in Cloud Computing. In SIGCOMM, 2012.
59 Lucian Popa, Praveen Yalagandula, Sujata Banerjee, Jeffrey C Mogul, Yoshio Turner, and Jose Renato Santos. Elasticswitch: Practical Work-Conserving Bandwidth Guarantees for Cloud Computing. In SIGCOMM, 2013.
60 Barath Raghavan, Kashi Vishwanath, Sriram Ramabhadran, Kenneth Yocum, and Alex C. Snoeren. Cloud Control with Distributed Rate Limiting. In SIGCOMM, 2007.
61 Waleed Reda, Marco Canini, Dejan Kostić, and Simon Peter. RDMA Is Turing Complete, We Just Did Not Know It Yet! In NSDI, 2022.
62 Alan Shieh, Srikanth Kandula, Albert Greenberg, Changhoon Kim, and Bikas Saha. Sharing the Data Center Network. In NSDI, 2011.
63 David Shue, Michael J. Freedman, and Anees Shaikh. Performance Isolation and Fairness for Multi-Tenant Cloud Storage. In OSDI, 2012.
64 Arjun Singhvi, Aditya Akella, Dan Gibson, Thomas F. Wenisch, Monica Wong-Chan, Sean Clark, Milo M. K. Martin, Moray McLaren, Prashant Chandra, Rob Cauble, Hassan M. G. Wassel, Behnam Montazeri, Simon L. Sabato, Joel Scherpelz, and Amin Vahdat. 1RMA: Re-Envisioning Remote Memory Access for Multi-Tenant Datacenters. In SIGCOMM, 2020.
65 Shin-Yeh Tsai, Mathias Payer, and Yiying Zhang. Pythia: Remote oracles for the masses. In 28th USENIX Security Symposium (USENIX Security 19), pages 693--710, Santa Clara, CA, August 2019. USENIX Association.
66 Ben Verghese, Anoop Gupta, and Mendel Rosenblum. Performance isolation: Sharing and isolation in shared-memory multiprocessors. In ASPLOS VIII, 1998.
67 Tao Wang, Xiangrui Yang, Gianni Antichi, Anirudh Sivaraman, and Aurojit Panda. Isolation mechanisms for High-Speed Packet-Processing pipelines. In NSDI, 2022.
68 Di Xie, Ning Ding, Y Charlie Hu, and Ramana Kompella. The Only Constant is Change: Incorporating Time-Varying Network Reservations in Data Centers. In SIGCOMM, 2012.
69 Understanding Performance of PCI Express Systems. https://docs.xilinx.com/v/u/en-US/wp350, 2018.
70 Xiao Zhang, Eric Tune, Robert Hagmann, Rohit Jnagal, Vrigo Gokhale, and John Wilkes. CPI2: CPU Performance Isolation for Shared Compute Clusters. In EuroSys, 2013.
71 Yiwen Zhang, Yue Tan, Brent Stephens, and Mosharaf Chowdhury. Justitia: Software Multi-Tenancy in Hardware Kernel-Bypass Networks. In NSDI, 2022.
附录 A 网络与 PCIe
要通过基于以太网的 IP 路由 RDMA 网络（即 RoCEv2）传输负载，网络协议引入以下开销。
-
以太网开销。 每个以太网帧包括 14 字节以太网（不含 VLAN）头部和 4 字节 CRC 作为 L2 开销。此外，每个以太网帧都有 L1 开销------每个帧前面有 7 字节前导码和 1 字节帧起始定界符。帧后面还跟有一个帧间间隙。该间隙应至少为 12 字节。因此，每帧的以太网总开销为 38 字节 23。
-
IP 开销。 IP 开销来自 IP 头部，最小大小为 20 字节。
-
UDP 开销。 UDP 开销来自 8 字节 UDP 头部。
-
Infiniband 开销。 Infiniband 协议在 UDP 负载内部实现头部。通过可靠连接（RC）的简单 WRITE 消息需要 12 字节基础传输头部（BTH）、16 字节 RDMA 扩展传输头部（RETH）和 4 字节不变 CRC。因此，Infiniband 协议开销至少为 32 字节 2。
要将负载从主机 DRAM 传输到 RNIC，RNIC 的 PCIe 行为包括以下开销。
-
响铃门铃。 要发布工作请求，用户需要通过内存映射 IO（MMIO）响铃 RNIC 的门铃。每个 MMIO 具有固定的对齐大小 64 字节。
-
工作队列元素。 RNIC 需要从主机 DRAM 获取工作队列元素（WQE）到网卡。RC/UC 的 WQE 为 36 字节，UD 为 68 字节。
-
TLP 开销。 每个 PCIe 事务都有 PCIe 事务层数据包（TLP）头部，不同 PCIe 实现的头部大小不同。根据 29,69，我们假设其最小大小为 20 字节。
接下来我们展示第 3 节中 29 字节负载示例的计算。29 字节负载显然小于 MTU，可以使用单个网络数据包发送。因此，此负载消耗的网络字节为：
Bytes(network) = Bytes(payload) + Bytes(Ethernet) + Bytes(IP) + Bytes(UDP) + Bytes(IB)
= 29 + 38 + 20 + 8 + 32
= 127 (bytes)对于 PCIe 消耗，29 字节负载大于最大内联大小（28 字节）。因此它不能与 WQE 在同一个 PCIe 事务中传输。它需要三个 PCIe 事务：（1）门铃，（2）WQE，和（3）负载，并消耗以下字节：
Bytes(PCIe) = Bytes(payload) + Bytes(payload TLP) + Bytes(WQE) + Bytes(WQE TLP) + Bytes(Doorbell) + Bytes(DB TLP)
= 29 + 20 + 36 + 20 + 64 + 20
= 189 (bytes)因此，当饱和链路容量（100 Gbps）时，此类负载的 PCIe 消耗为：
Bandwidth(PCIe) = Bandwidth(network) * Bytes(PCIe) / Bytes(network)
= 100 * 189 / 127
= 148.8 (Gbps)附录 B 网卡供应商的回应
我们向网卡供应商（包括 NVIDIA、Intel 和 Chelsio）报告了我们的发现和结果。NVIDIA 是最大的 RDMA NIC 供应商之一，他们在确认和复现我们的实验方面投入了大量精力。他们已在自己的环境中成功复现了我们所有的发现。此外，NVIDIA 为我们提供了详细的分析和反馈。我们想在这里分享它们。
关键发现 #1：控制动词可能导致过多的缓存未命中和严重的性能下降。 NVIDIA 提供了对此发现的更准确分析：注销控制动词可能导致严重性能下降，主要是因为 NIC 内部 QoS 调度策略。注销控制动词的优先级高于其他类型的操作，将首先被调度。因此，这些注销动词触发过多的缓存未命中，导致性能急剧下降。NVIDIA 已经想出了解决此问题的方案。高层思路是调整 NIC 内部 QoS 策略，使注销不具有如此高的优先级。他们正在计划进行固件升级以修复此问题。
关键发现 #2：不同数据动词之间的性能干扰取决于动词的复杂性。 NVIDIA 熟悉这种现象，并将推出新的固件升级来解决此问题。
关键发现 #3：错误处理可能暂停 RNIC 处理单元并挂起所有应用。 NVIDIA 提供了对此现象的更准确解释：对于不可靠传输类型（UC 和 UD），没有与 RC 相同的特定 RNR 异常处理程序。相反，它们有其他处理逻辑，涉及处理乱序数据包的固件。这是使用不可靠传输类型进行攻击时性能干扰的根本原因。NVIDIA 还提供了缓解此类干扰的潜在解决方案。NVIDIA Connect-X 系列网卡支持监控每个 VM 的 NIC 资源消耗。因此，云运营商可以基于 NIC 资源消耗的可见性来强制执行 VM 能力策略。此外，NVIDIA 计划在即将推出的 NIC 固件/硬件版本中引入额外的保护层，以完全消除 RC 的攻击向量。
关键发现 #4：只有当请求大小在特定范围内时，PCIe 带宽才会成为瓶颈。 尽管 PCIe 带宽争用不是 RDMA 带来的独特干扰，NVIDIA 仍然承认并确认了我们关于 RDMA NIC PCIe 消耗的观察。
我们感谢 NVIDIA 的友善和大力支持。我们相信上述理解将使云运营商和 RDMA 应用开发人员受益。此外，我们与 NVIDIA 的合作也展示了 Husky 如何帮助改进现有 RDMA 解决方案并在未来构建稳健的 RDMA 性能隔离。