FreeFlow：Software-based Virtual RDMA Networking for Containerized Clouds

nsdi‘19 Carnegie Mellon university

github：https://github.com/Microsoft/Freeflow

简介：

主要工作为提供了一个基于软件的容器化RDMA解决方案，性能与在裸机上运行RDMA网络具有可比性。

FreeFlow的核心是一个运行在每台服务器上的软件虚拟交换机，目的是将通用的RDMA网卡虚拟化。此方案与基于TCP/IP网络的容器云OVS交换机解决方案类似，依据RDMA的特性增加了修改。

方案设计的两个挑战：（1）FreeFlow必须对应用完全透明。挑战在于RDMA需要网卡操作内存和文件描述符，但容器内的应用由于网络虚拟化不会与网卡直接交互的。FreeFlow的做法是让容器内应用于网卡共享内存和文件描述符。通过尽可能小的修改，使容器内的资源从非共享变为共享。（2）FreeFlow必须拥有可与裸机RDMA媲美的吞吐量、时延、CPU利用率等性能。作者将性能瓶颈锁定在内存拷贝和进程间通信，于是设计了零拷贝（吞吐量）和进程间通道共享内存（时延）解决方案。同时，作者还设定了CPU开销上限来优化FreeFlow性能。

开源：https://github:com/Microsoft/Freeflow

背景：简单介绍了容器网络和RDMA网络，表明容器网络的virtual mode具有的高度隔离性、可移植性、数据平面和控制平面可控性十分契合需求。RDMA网络是将大部分报文解析和处理操作卸载到网卡上进行，因此可获得高性能。所以，问题的根源在于，怎样在需要virtual mode网络的容器应用中使用RDMA网络，尤其是在云环境中。

目前已有的SR-IOV硬件解决方案不具有可移植性。SR_IOV是将网卡切分成多份，每个容器使用单独的网卡资源，这样容器间的通信就要依赖底层的物理交换机，在迁移容器后，物理交换机上的路由表也需要重新配置。此外，随着容器规模的扩大，物理交换机内转发表也越来越大，不具有扩展性。于是，作者提出基于软件的解决方案才是可行的。目前基于TCP/IP协议栈的容器云就是通过软件交换机（OvS）通信的，如右图。

软硬件解决方案对比

设计综述：

设计架构，灰色部分为作者实现部分

FreeFlow NetLib（FFL）：集成了RDMA协议框架中的IB verbs API，通过这些API应用可以操作FreeFlow Router上的队列，进行读写或监控。

FreeFlow Router（FFR）：在虚拟网卡上集成了QP，CP，并将虚拟网卡的上的操作与物理网卡关联起来

FreeFlow Orchestrator（FFO）：执行控制策略，查看运行状态数据

FFL位于每个容器内部，是使FreeFlow对于应用呈透明化的关键，只要支持IB verbs API的应用都可以直接或经过微小的修改就可以直接运行。与FFR配合使用。FFR是位于每个主机内的一个容器化路由器实例，为同一主机上的所有容器提供虚拟网络。在数据平面，FFR与同一主机上的容器共享内存。FFR通过网卡发送或接收共享内存中的数据，然后通过FFL将操作的数据同步到容器应用的私有内存中。

难点在于：（1）FreeFlow要提供一个支持所有现存RDMA操作的接口（2）性能要与裸机相比具有可比性。FFL和FFR之间的通信设计要非常巧妙。

设计细节：对RDMA操作的透明支持

难点：对单边操作和基于事件的通知消息的支持。原因在于RDMA网卡可以自主修改FFR中的内存和文件描述符，而不用通知FFR，FFR只有频繁轮询内存或文件描述符状态才能将物理网卡的操作同步到容器应用中的虚拟网卡上。

解决方案：利用容器的可操作特性，使FFR和FFL共享内存和文件描述符，这样物理网卡的操作就可以自动同步到容器内。由于容器应用不能在进程间通信的共享内存空间分配内存，所以作者需要将容器内存转换为共享内存。

连接建立：

连接建立过程

通过连接建立，容器应用在vNIC中建立了QP和CQ，注册了mem，FFR在物理NIC上也建立了QP'和CQ'，并与容器应用关联，同时也在IPC共享内存中注册了s-mem，并将内存ID号告知FFL，实现内存映射。这样的连接过程增加了一些FFL和FFR的交互操作，增加了时延，但由于连接的可重用性，此开销相对于传输时延来看可忽略。

双边操作：

send：应用调用send函数，将指针指向mem，FFL将mem数据拷贝到s-mem，FFR调用send将s-mem发送出去。后续会讲避免拷贝的操作。

recv：当物理网卡中的QP'队列不再接受数据，FFL将数据从s-mem拷贝到mem中。

单边操作：

保证零拷贝设计

问题和挑战：（1）单边操作的远端内存地址是mem，如图(a)所示，远端对mem2并没有操作权限。为解决此问题，FreeFlow采用在FFO中建立映射表的方式，将所有mem和s-mem的映射关系都提前加载到FFR中的方式，解决问题（a）。（2）由于单边操作没有CQ队列，所以接收端无法感知单边操作是否完成，无法确定何时将s-mem的数据更新到mem中。解决方案是不断同步s-mem和mem，但这会带来大量的CPU开销和存储总线带宽占用。

解决方案：（1）作者创建了两个新的API，使得容器应用FFL可以直接将mem分配到可以与FFR共享的内存中，从而避免拷贝。缺点是需要修改几行应用的代码。（2）将应用的虚拟内存地址重映射到共享内存中。在linux中，此操作只有当虚拟内存地址在内存页的开始时才有效，所以FFL强制将地址分配在内存页的开始，实现内存页对齐。这样不用修改应用代码，但会造成主机内存使用效率低下。

基于事件的操作：

解决的问题是：如何从CQ队列中获得RDMA操作已经完成的通知。

方法：（1）应用通过轮询不断检测CQ队列，是否有已经完成的操作（2）应用创建事件通道，将CQ队列绑定到事件通道上，当RDMA操作完成时，事件通道中包含的文件描述符会触发事件。在FreeFlow中，由于原始的文件描述符是在物理网卡上创建的，所以FFR必须将原始文件描述符传递给FFL，才能触发应用中的事件。作者利用FFR和FFL共享OS内核的便利实现这两个进程间传递文件描述符，从而实现事件通道的传递。

FFL和FFR之间的通信通道

FFL和FFR的通信方式

在FreeFlow中，FFL截断了所有的verbs call，然后通过FFR将其转发到物理网卡上执行。为保证性能，需要在FFL和FFR之间建立高效的通信方式，才能保证它不是RDMA性能的新瓶颈。

通过文件描述符实现verbs转发

简单想法是，通过RPC，FFL将verbls call的函数名，参数传递给FFR，FFR经过简单修改参数，执行函数，并将结果返回给FFL。但由于verbs call的参数数据结构过于复杂，如图（a），指针的传递在不同进程之间是无效的，所以RPC不可用。接着考虑“深拷贝”，将所有指针指向的数据结构全部传给FFR。这种方式由于（1）数据结构过于深，包含多级指针和封装，深拷贝会大大损伤性能（2）有些数据结构与应用相关，不可能在FreeFlow中预定义，两条严重的弊端，被pass掉。

根据图（b）中verbs库的结构，中间阴影部分，作者发现中间层（NIC Driver Communicator）与NIC 文件描述符通信的数据结构是不含指针的简单的数据结构，硬件网卡可以很容易解析。因此，在FreeFlow中，作者将容器中的NIC File Descriptor替换掉，换成unix socket file descriptor，这是在FFL中实现的。FFL将转发NIC Driver Communicator向NIC file descriptor的请求命令和参数给FFR，FFR执行完相应命令后，将结果传递给Unix socket file descriptor。在整个操作过程中，NIC Driver Communicator是无感知的。

这种方法的缺点是FFL和FFR之间的socket通信有时延，且很容易超过5us（unix socket的rtt），对于时延敏感的应用，要求小于5us，socket通信将会成为瓶颈。

通过FastPath实现FFL和FFR的通信

通过专用共享内存片进行通信。FFR占用一个CPU内核，不断检测是否有FFR写入专用共享内存片中的新请求。一旦检测到新请求，FFR立即执行，FFL占用一个CPU内核不断检测是否有回复消息写入专用共享内存片中。读取回复消息后，FFL停止对CPU内核的占用。

FastPath

缺点：增加了读取请求和回复消息的CPU周期。

为限制增加的CPU开销，作者做了一下限制：（1）每个主机上FFR仅占用一个CPU内核（2）FastPath只用于操作数据平面的、无锁的函数调用。如果FFO知道应用为非时延敏感的，则禁用FastPath。

实现

FFL和FFR的实现都是修改和补充了原有verbs的相关库。FFO是用ZooKeeper实现的，用于存储用户定义的信息。

discussion

CPU开销：FreeFlow会不可避免的引入CPU开销，主要是在FastPath上，需要占用一个CPU内核资源。作者表明之后可以利用支持卸载CPU任务的硬件来负担轮询的任务，例如FPGA、ARM或者RDMA NIC等。

安全性：由于FFR与容器在注册内存时使用的是IPC的共享内存，所以存在容器A读取同一主机上其他容器内存数据的隐患。作者表明不同容器的私有QP会有专用的共享内存片，不会存在安全问题。另一个担忧是在单边操作中，操作的内存秘钥被监听导致信息泄露的问题，作者表明这是RDMA单边操作固有的问题，与FreeFlow无关。

与外部非FreeFlow的源端进行RDMA操作：作者表明每个FFR都是独立运行的，所以使用FreeFlow机制的主机可以无感知的与普通RDMA远端进行数据传输，FFR并不会识别对端是另一个FFR还是RDMA网卡。

容器迁移：容器在迁移过程中不会改变IP地址，所以只需要在重启后重新与对端建立连接即可。FFR不支持热迁移。

VM 主机：作者表明所有实验都是在运行在裸机上的容器进行的，若要将容器运行在虚拟机上，需要VM使用SR-IOV技术接入物理RDMA网卡。