摘要
1. 介绍
大型云应用开发者一直在追求高性能、低运维成本和高资源利用率，导致容器化和远程直接内存访问（RDMA） 络技术被越来越多的采用。
容器[7,11,6]提供的轻量级隔离和可移植性，降低了部署和管理云应用的复杂性(从而降低了成本)。因此，现在容器成为管理和部署大型云应用的实际方式。
因为与基于标准TCP/IP的 络相比，RDMA 络能够提供更高的吞吐量、更低的延迟和更少的CPU占用，所以许多数据密集型应用（例如，深度学习和数据分析框架）都会采用RDMA [24,5,18,17]。
但不幸的是，这两种技术趋势在云环境中是相互矛盾的。容器化的核心价值是为应用提供高效灵活的管理。为此容器云需要容器在 络中具有以下三个属性：
隔离：每个容器都应该有其专用的 络命名空间（包括端口空间、路由表、接口等），以消除与同一主机上其他容器的冲突。
可移植性：容器应该使用虚拟 络与其他容器通信，并且与它的虚拟IP保持关联，而不管它被调度到哪个主机上或迁移到哪个主机上。
可控性：编排器可以容易地执行控制平面策略(例如，准入控制、路由)和数据平面策略(例如，QoS、计费)。此属性在(多租户)云环境中尤其需要。
对于在云环境中，自由放置、迁移容器、以及控制每个容器可使用的资源，这些属性都是必需的。为此，在基于TCP/IP的操作中， 络可以通过软件（虚拟）交换机来实现完全虚拟化[15]。
但是，很难对基于RDMA的 络进行完全虚拟化。 RDMA通过将 络处理卸载到硬件NIC中，绕过内核软件栈，实现了高 络性能。 在共享的云环境中难以修改硬件中的控制平面状态（例如，路由），同时由于流量直接通过PCIe总线在RAM和NIC之间传输，也难以控制数据路径。
因此，采用这两种技术的几个数据密集型应用（例如，TensorFlow [24]，CNTK [5]，Spark [18]，Hadoop [17]）仅在专用裸机群集中运行时才使用RDMA; 当在共享的云环境中运行时，不得不完全摒弃RDMA提供的性能优势。 当然，使用专用集群来运行应用对于提供商或客户来说都是不划算的。
表2显示了使用RDMA进行通信的深度学习应用的性能改进 – 训练Recurrent Neural Network（RNN）语音识别模型。该应用程序首先在具有8个GPU的单台机器上进行基准测试。当应用程序在具有16个GPU的两台计算机上运行时，传统的TCP/IP 络成为瓶颈，性能的提升下降。但是使用了RDMA，额外GPU可以显著提高性能。
上述现象的原因是，RNN训练任务包含数千个步骤。在每个步骤中，所有GPU都必须对训练模型参数进行shuffle（即随机重排列），总流量大约在100MB到10GB。花在通信上的时间实际上是浪费GPU的时间，因为GPU在shuffle期间处于空闲状态。TCP在这些频繁和突发的工作负载中表现不佳，而RDMA可以在每次shuffle开始时瞬间爬升到全带宽。
对于基于软件的RDMA虚拟化的需求：
我们已经注意到了虚拟模式 络对容器应用程序的好处，即增强的隔离性、可移植性和可控性。同时，RDMA还可以为许多具有微服务架构的应用程序提供显著的性能提升。
那么问题是，我们如何将RDMA 络与需要虚拟模式 络的容器应用程序结合使用，尤其是在云环境中。
Verbs：RDMA的“窄腰”
有多种方法可以拦截应用程序和物理 卡之间的通信，但我们必须选择有效的方法。 目前有许多支持RDMA的商业技术，包括Infiniband [9]、RoCE [8]和iWarp [19]。应用程序还可以使用几种不同的高级API来访问RDMA功能，例如MPI和rsocket [20]。如图3所示，这些API事实上的“窄腰”是IB Verbs API（Verbs）。因此，我们有意识地选择在FreeFlow中支持Verbs，这样我们就可以自然地支持所有更高级别的API。
挑战
在设计FreeFlow时，我们需要解决两个关键挑战。首先，FreeFlow应该提供一个RDMA接口，它透明地支持所有类型的现有RDMA操作。存在各种类型的RDMA操作，包括用于数据传输的单侧和双侧操作，用于工作完成通知的轮询和基于事件的机制，以及用于连接建立的TCP/IP和RDMA-CM。我们观察到，由于RDMA操作的复杂性，透明地支持它们并不简单。其次，FreeFlow应该提供接近裸机的RDMA性能，同时最小化CPU和内存开销。由于FFR通过FFL接受来自应用程序的Verbs调用，所以我们需要仔细设计FFR和FFL之间的通信通道。我们将分别针对§4和§5中的每个挑战提出我们的方法。
4. RDMA操作的支持
Verbs 支持多种操作和机制。使用WRITE/READ单方操作，读取（写入）方可以读取（写入）远端服务器特定内存地址的数据，而不需要事先通知对方。使用SEND/RECV双方操作，发送方必须在接收方准备好接收数据之后才能发送数据。此外，程序也可以使用基于拉取或者基于事件的机制来处理任务完成通知。不同的程序根据自己的需要选择不同的操作方式，我们发现在常用的应用程序中，这几种操作都被使用到。[32、18、17、22]
FreeFlow完全透明地支持这些不同的RDMA操作。主要的挑战是支持单方操作和基于事件的完成通知，因为，RDMA 卡会悄无声息的修改FFR使用的内存或者文件描述符。FFR如果不持续的频繁检查内存或者文件描述符的话是不会马上发现变更的，所以，及时的将物理 卡上的操作转换到容器中的虚拟 卡上是非常困难的。但是，容器终归是进程，FFL和FFR可以共享内存和文件描述符，借助这个特点我们解决了这个问题，让物理 卡所做的操作可以自动的传入容器中。将应用程序的内存在FFL和FFR之间共享也不是很容易，因为，容器内的应用程序不会在IPC共享内存区申请内存，所以，我们需要将容器中的内存转换成共享内存。
建立连接
两个RDMA通信端首先需要建立连接。它们在各自的 卡上创建QP，并为QP申请一个内存缓存，然后与远端的QP进行配对。当连接建立后，应用程序会要求NIC将本地缓存中的内容发送到远端，或者将收到的内容放到本地缓存中。
在单方操作中，客户端不止需要服务端的GID，同时还需要远端内存缓存的地址，以及访问内存所需的密钥。这些信息会在图5的第五步时进行交换，然后在第八步执行读写操作时使用。
与双方操作相比，单方操作的透明支持更加有挑战性。在FreeFlow中支持单方操作需要面临两个问题。
首先，目标存储器地址mem位于远程容器的虚拟存储器中。但是，本地FFR不知道另一方的相应s-mem。例如，在图6（a）中，当发送方试图将mem-1中的数据写入远程存储器mem-2时，它在阶段3）就失败了，因为接收器上的FFR无法访问目标存储器地址mem-2 。
为了解决这个问题，FreeFlow在FFO中为所有FFR构建了一个中心键值存储，以保存应用程序虚拟内存空间中mem指针与FFR虚拟内存空间中相应s-mem指针之间的映射。当应用程序将内存注册到其虚拟NIC时，更新此表会增加图5中步骤3的延迟。但是，数据平面性能不会受到影响，因为FFR可以在本地缓存映射。
其次，即使我们知道远程端的内存映射，WRITE和READ也可以远程修改或复制数据而不通知远程端的CPU，因此，FFR不知道何时复制到应用程序的存储器或从应用程序的存储器复制。例如，在图6（b）中，发送方找到s-mem-2的正确地址并将数据发送给它。但是，在s-mem-2中有数据后，没有通知接收器的FFR知道何时将s-mem-2复制到mem-2。解决此问题的一种方法是不断同步s-mem-2和mem-2。 当然，这会消耗大量的CPU和内存总线带宽。
为了解决这个问题，我们在FreeFlow中设计了一个基于零拷贝的机制来有效地支持单方操作。高级想法是使mem和s-mem具有相同的物理内存，因此FFR不需要进行任何复制，数据将自然地呈现给应用程序。图6（c）说明了这种设计。通过删除内存副本，我们还可以提高FreeFlow的性能。
这里的关键是使应用程序直接分配和使用共享内存与FFR进行数据传输。为此，FreeFlow提供了两个选项：
选项1 – 创建新的API来分配共享内存：我们创建两个新的Verbs函数，ibv _malloc和ibv_free，让应用程序将内存创建和删除委托给FreeFlow。这允许FFL直接在共享内存区域中分配这些缓冲区（与FFR共享），从而避免复制。这个选项的缺点是需要修改应用程序代码，尽管修改应该只是数据缓冲区创建的几行。
选项2 – 将应用程序的虚拟内存地址重新映射到共享内存：当应用程序将虚拟内存地址va作为数据缓冲区注册到私有内存块时（例如，图5中的步骤3），FFL释放物理内存记忆片后面的va，并从FFR到va分配一个共享的物理内存片。在Linux中，此操作仅在va是内存页面开头的地址时有效。为了强制应用程序始终在页面的开头分配内存，FFL拦截C语言中的malloc之类的调用，并使其始终返回页面对齐的内存地址。虽然此选项可以在不修改应用程序代码的情况下实现零内存复制，但它会强制应用程序中的所有内存分配进行页面对齐，这会导致主机上的内存效率降低。
在实践中，我们建议使用第一个选项，因为它更清洁，更高效。但是，由于许多RDMA应用程序已经使它们的数据缓冲区页面对齐以获得更好的性能（例如，RDMA-Spark [18]），我们可以直接使用第二个选项而不拦截malloc，因此副作用有限。请注意，不管开发人员选择使用选项1修改应用程序，还是应用程序本来就支持页面对齐缓冲区，FreeFlow都不会在实际内存使用中产生任何开销。
基于事件的操作
从CQs（完成队列）中获取信息有两种方式。一种是让应用定时检查队列中是否有结束的操作。另一种是基于事件的，由应用创建一个事件管道，然后将CQ加入管道。当有操作完成时可以通过管道中的文件描述符触发相应的事件。
在FreeFlow中，由于原始文件描述符是由物理 卡创建的，FFR需要将文件描述符传递给FFL，否则后者无法感知与文件操作符相关的事件。但是FFL、FFR本质上共享同一个内核的两个进程，借助此特点也可以实现进程间文件描述符的传递，由此我们实现了将事件管道从FFR传递给了FFL。
5. FFL和FFR之间的通信通道
由于FreeFlow通过FreeFlow 络库(FFL)截取每个Verbs调用，解释并通过FreeFlow软件路由器(FFR)将它们转发到物理 卡，因此，在FFL和FFR之间建立有效通道以提供高RDMA性能，同时最小化系统资源消耗至关重要。在本章中，我们提出了两种这样的通信信道设计，它们允许用RDMA性能来换取资源消耗量，反之亦然，这取决于应用的要求。
Verbs通过文件描述符转发
为了加速FFR和FFL之间的通信，我们设计了一个与它们之间基于Unix套接字的通道并行的Fastpath。如图8所示，FFL和FFR共同拥有一块专用的共享内存。使用Fastpath，FFR在CPU内核上自旋并持续检查是否有来自FFL的新请求被写入共享内存块。一旦检测到请求，FFR将立即执行它，同时FFL开始在CPU内核上自旋以检查是否完成响应。在读取到响应后，FFL将停止它的CPU自旋。
正如我们将在第8.1.2节中看到的，Fastpath可以显著减少延迟。但代价就是用于读取请求和响应的自旋所花费的CPU开销。为了限制Fastpath带来的CPU开销，我们做出两个设计决定：
（1）对于同一主机上具有FFL的所有Fastpath通道，FFR仅在一个CPU内核上自旋。
（2）Fastpath仅用于数据通路上的非阻塞功能，使得FFL上等待响应的CPU旋转时间会很短（几微秒）。
总的来说，Fastpath平均每个主机仅消耗一个CPU内核，以显著缩短消息传递的延迟（第8.1.2节）。 另外，如果FFO知道主机上没有对延迟敏感的应用程序（根据运行的容器镜像），它可以禁用Fastpath和CPU自旋。
6. 实现
我们通过修改libibverbs (v1.2.1)、 libmlx4 (v1.2.1) 和librdmacm(v1.1.0)来实现FreeFlow 络库（FFL）[注4]。添加了大约4000行C代码来实现FreeFlow的逻辑。我们大约通过2000行C ++代码实现了FreeFlow软件路由器（FFR）。对于FreeFlow 络协调器（FFO），我们使用ZooKeeper来存储用户定义的信息。比如，IP分配、访问控制、资源共享策略和单侧操作的内存映射信息。由于篇幅限制，我们接下来只展示三个代表性的实现细节。
控制和数据层面策略
由于FreeFlow可以控制容器请求的控制和数据层面操作，因此它可以支持常见的控制和数据层面策略，包括带宽执行策略、流优先级划分策略和资源使用执行策略。
作为控制层面策略的一个例子，在我们的原型中，FreeFlow对每个容器可以创建的QP（queue pair）数量进行限额，因为大量的QP是RDMA 卡性能下降的主要原因[32]。此控制层面策略可防止容器创建太多QP影响同一主机上的其他容器。
我们在FFR中实现了一个简单的令牌桶数据结构。当应用程序创建新QP时，我们检查存储在FFO中的策略，并将有预设速率限制的令牌桶关联到QP。在每个应用程序发送请求时，路由器会检查QP是否有足够的令牌去发送请求消息。如果有，则立即将发送请求转发给物理 卡。否则，FFR将通知FFL并将其延迟，直到有足够的令牌。请注意，它只是实施QoS策略的一个示例。FreeFlow提供了灵活的API，用于在FFR中实现复杂的QoS算法，而由于篇幅限制，我们省略了细节部分。
Fastpath内存管理
在Fastpath实现中，我们使用汇编代码显式强制地将FFL和FFR写入的请求和响应的缓存行立即刷新到主存储器中。这是必要的，否则CPU会将新写入的行保留一段时间，以等待更多写入行，从而减慢Fastpath上的信息交换速度。
支持并行
由于应用程序可以创建多个QP，并使用多个线程来并行传输数据，因此FFL和FFR之间的每个Unix域套接字都需要锁定。为了提高性能，我们在FFL和FFR之间创建了多个Unix域套接字。为避免排头阻塞，我们将更多套接字专用于数据层面操作和事件通知，并仅使用一小部分套接字用于创建、设置和删除操作。在FFR上，我们为每个传入的Unix域套接字连接使用专用线程。我们还为每个容器创建专用数据结构，并为每个已注册的内存缓冲区创建专用共享内存区域，以保持数据路径无锁。
注4：libibverbs和librdmacm是允许用户空间进程分别使用InfiniBand / RDMA Verbs和RDMA通信管理器接口的库。libmlx4是libibverbs的用户空间驱动程序，允许用户空间进程使用Mellanox硬件。
7. 讨论
在本节中，我们将讨论当前FreeFlow设计中的一些主要问题和潜在扩展。
CPU开销：与基于软件的TCP / IP虚拟 络解决方案类似，FreeFlow会产生CPU开销。特别是，FreeFlow使用CPU内核在FFL和FFR之间轮询控制消息，以支持低延迟IPC通道（第5.2节）。我们承认，这个是在当前商品硬件之上进行 络虚拟化的成本。解决这个问题的一种可能方法是利用支持卸载CPU任务的硬件，例如FPGA、ARM协处理器或RDMA 卡[1]。我们如何消除Fastpath中的CPU开销，将作为我们未来的工作。
安全性：一个问题是由于FFR与容器共享其内存，因此一个容器是否可以通过扫描IPC空间来读取同一主机上其他容器的通信。这不是FreeFlow的问题，因为FFR为每个单独的QP创建了专用的共享内存缓冲区。只有属于容器的共享内存缓冲区才会映射到容器的虚拟内存空间。另一个问题是存储键的安全性，如果可以通过窃听看到密钥，则后续通信可能会受到影响。这个问题与原始RDMA工作中的单边操作有关，并且FreeFlow不会使其变得更糟糕。
使用外部传统对等体：FreeFlow中的容器可以自然地与外部RDMA对等体通信，因为每个FFR都能独立工作。FFR不会区分远程对等体是另一个FFR，还是外部RDMA对等体。
容器迁移：FreeFlow自然支持离线迁移。如果在另一台主机上捕获、关闭、移动和重新启动容器，则其IP地址不会更改，以便其对等方重新建立RDMA连接，就像它刚刚重新启动一样。如今，离线迁移通常用于容器集群中，以进行资源打包或故障转移。FreeFlow不支持实时迁移，因为现在RDMA的移动性还很差[39]。
VM主机：我们的原型（和评估）是基于在裸机主机上运行的容器。但是，如果VM使用SR-IOV访问物理NIC，则FreeFlow可以直接用于部署在VM中的容器。
拥塞控制：RDMA 卡已经拥有拥塞控制机制，并且FreeFlow依赖于它们。
8. 评估
我们评估了FreeFlow的性能和开销。我们将从微基准和FreeFlow上的实际应用程序的性能开始进行评估。
微基准测试
设置：我们在两个测试台上运行微基准测试。一个测试平台运行在In?niBand，这是一种传统的RDMA专用结构。这些服务器配备两个Intel Xeon E5-2620 2.10GHz 8核CPU、64GB RAM和56Gbps Mellanox FDR CX3 NIC。操作系统是Ubuntu 14.04，内核版本为3.13.0-129-generic。
另一个测试平台运行RoCE（RDMA over Converged Ethernet）。顾名思义，RoCE只需要传统的以太 交换机（在我们的例子中，Arista 7050QX作为ToR交换机）。此测试平台群集中的服务器具有Intel Xeon E5-2609 2.40GHz 4核CPU、64GB RAM、40Gbps Mellanox CX3 NIC和Ubuntu 14.04以及内核版本4.4.0-31-generic。
我们使用Docker（v1.13.0）[7]运行容器，并使用Weave（v1.8.0）[23]设置基本的TCP / IP虚拟 络，并启用Open vSwitch内核模块。除非另有说明，否则我们运行Fastpath（§5.2）启用FreeFlow。
我们主要将FreeFlow与裸机RDMA进行比较，后者是“最佳”性能的替代品。我们将展示FreeFlow为容器启用虚拟RDMA 络，而性能损失最小。在8.1.4中，我们还将演示在FreeFlow上将TCP套接字调用转换为RDMA的性能，这样传统的TCP应用程序也可以从FreeFlow中受益。我们还将FreeFlow与裸机TCP和Weave进行了比较，后者支持容器的虚拟TCP / IP虚拟 络。
吞吐量和延迟
我们专注于两个基本性能指标，即吞吐量和延迟。我们使用Mellanox perftest [13]提供的基准测试工具：ib_send_lat和ib_send_bw测量延迟和通过双边操作（SEND），ib_write_lat和ib_write_bw进行单向操作（WRITE）。这些工具可以在FreeFlow上运行而无需任何修改，如4.3中所述。一般而言，FreeFlow不区分主机间设置（在不同主机上运行的发送方和接收方）和主机内设置。这里我们只显示主机间性能值。
吞吐量：我们测量两个测试平台上的单线程RDMA SEND / WRITE吞吐量，并在图9中显示RDMA SEND结果。每次运行都传输1GB数据，不同大小的消息范围从2KB到1MB。 FreeFlow RDMA WRITE结果实际上略好于SEND，为简洁起见省略。我们看到，当消息大小等于或大于8KB时，FreeFlow将获得全吞吐量作为裸机RDMA（InfiniBand为46.9Gbps，RoCE为34.5Gbps）。此外，当我们将并发容器对（流量）的数量增加到512时，所有流量的聚合吞吐量仍然接近最优（图11）。我们还通过计算Jain的公平性指数[31]（平均0.97）来验证带宽在不同流量之间的公平分配。
通常，需要大量带宽的应用程序倾向于使用比几KB更大的消息大小。例如，在我们使用RDMA的一个内部存储群集中，典型的消息大小为1MB或更多。在这种情况下，FreeFlow将没有吞吐量损失（关于CPU开销，请参见8.1.2）。
即使消息很小，如2KB，FreeFlow仍然可以达到全部吞吐量的一半以上。我们验证了在这种情况下，吞吐量受单个FFR Fastpath线程（第5.2节）的限制。通过为FFR分配一个CPU核心，并在两个核心之间平衡RDMA请求负载，可以轻松消除此瓶颈。虽然我们将此选项保持打开状态，但开发人员通常不希望使用小消息来满足整个带宽。相反，对于小消息，开发人员通常关心延迟。
延迟：我们分别测量发送64B、256B、1KB和4KB消息的延迟。与吞吐量基准测试一样，两个容器在通过相同ToR交换机连接的不同主机上运行。对于每个消息大小，我们测量延迟1000次。我们绘制了中位数、第10和第99百分位潜伏期值。
我们演示了§6中提到的速率限制器的性能。在图13中，我们在InfiniBand测试平台上的不同主机上的两个容器之间启动单个流。我们限制流量并将不同的带宽上限从1Gbps设置为40Gbps。我们看到受控带宽（y轴）接近我们设定的带宽上限（x轴）。FreeFlow只需6％的CPU开销即可实现这一目标。
FreeFlow可以使用速率限制器隔离不同容器的性能（即吞吐量）。为了证明这一点，我们在容器对之间运行了10个并发流，并对每个流应用了不同的速率限制（从1到10Gbps）。我们确认每个流量的吞吐量都是准确的上限。
RDMA上的TCP套接字
启用虚拟RDMA还可以提高基于套接字的应用程序的性能。下面我们展示FreeFlow在rsocket（现有的socketto-Verbs转换层）的帮助下，提供比传统TCP / IP虚拟 络更好的性能。
我们在InfiniBand和RoCE集群上进行实验。通过在运行时动态链接rsocket，应用程序套接字调用被透明地转换为RDMA Verbs调用。我们运行iperf [10]来测量TCP吞吐量，NPtcp [14]用于TCP延迟，而不对这些工具进行任何修改。我们与在虚拟和主机模式 络上运行的相同工具进行比较。
对于图像识别，我们运行三个特定模型，ResNet-50 [29]、Inception-v3 [42]和AlexNet [33]。我们使用合成的Image Netdata作为训练数据。图15（a）显示了具有10百分位数和99百分位数值的每秒中值训练速度。根据所有三种不同模型的结果，我们得出结论，首先， 络性能确实是分布式培训的瓶颈。将主机RDMA与主机TCP进行比较，主机RDMA在训练速度方面的性能提高了1.8到3.0倍。容器覆盖层上FreeFlow和Weave之间的差距更大。例如，FreeFlow在AlexNet上的运行速度提高了14.6倍。其次，FreeFlow性能非常接近主机RDMA。差异小于4.9％，FreeFlow有时甚至更快。我们推测这是由于测量噪声造成的。
对于语音识别，我们运行一个私有语音RNN模型，该模型由双向编码器和完全连接的解码器层组成，隐藏层维度为1024，词汇量大小为100k。数据集大小为4GB，包括1860万个样本。在每个训练步骤中，GPU从一小块“学习”并相互通信以进行同步。图15（b）显示了每个训练步骤所花费时间的CDF，包括GPU时间和 络时间。同样，FreeFlow非常接近主机RDMA。中位数训练时间比Weave快8.7倍。
Spark
我们在两台服务器上运行Spark（v2.1.0）。其中一个服务器运行一个主容器，用于调度从属容器上的作业。两个服务器都运行从属容器。Spark [18]的RDMA扩展是由闭源实现的。我们从他们的官方 站下载了二进制文件，并没有进行任何修改。
我们演示了Spark发行版附带的基本基准测试 – GroupBy和SortBy。每个基准测试运行262,144个键值对，值为2 KB。我们将Spark映射器和Reducer的数量设置为8，并且每个都是单个线程。图16显示了结果。我们总结了与运行TensorFlow相似的观察结果。 络的性能确实会显著影响应用程序的端到端性能。使用FreeFlow运行时，性能非常接近在主机RDMA上运行，优于主机TCP，并且比使用Weave运行容器的性能高出1.8倍。
9. 相关工作
容器中的RDMA虚拟化：Mellanox正在努力扩展Linux内核中的 络namespace和cgroup，以适应RDMA的 络隔离[34,35]。使用MACVLAN将物理接口拆分为多个虚拟接口，为每个容器插入一个或多个接口，并依靠VLAN路由将流量传递到正确的虚拟接口。 显然，它在云环境中会有可移植性问题，因为移动IP意味着更新硬件中的VLAN路由。此外，它不提供灵活的可控性，因为它允许容器直接访问物理NIC。
另一种方法是使用可编程硬件来处理容器的RDMA虚拟化，例如智能NIC [26]或FPGA [38]。与基于硬件的解决方案相比，FreeFlow的优势在于使用商用硬件降低了成本，并且可以更灵活地定制 络功能。
VM的RDMA虚拟化：HyV [39]是最接近FreeFlow的解决方案。它还拦截应用程序和NIC驱动程序之间的通信，并提供地址转换、QP/CQ映射和内存映射。HyV和FreeFlow的主要区别在于HyV不控制数据路径以在私有集群中提供裸机性能，而FreeFlow适用于云环境。这给FreeFlow带来了更多挑战，例如使性能仍然接近裸机质量，同时保持数据路径中应用程序的透明性。VMM旁路I/O [37]具有与HyV类似的设计和问题。VMware一直致力于对称为vRDMA的RDMA设备进行半虚拟化[40]。vRDMA专为VMware的虚拟机管理程序和虚拟机而设计，因此，它本身并不适用于容器。
10. 结论
参考文献请查看原文链接，原文地址：
https://www.usenix.org/conference/nsdi19/presentation/kim
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8615 人正在系统学习中 相关资源：国内领先的在线试衣间软件3D试衣间_github3D试衣间源码-互联 …
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！