加速NFV（网络功能虚拟化）数据面：SR-IOV和DPDK[原文意译]

事实确实如此 - 过去不少人都在谈论SR-IOV和DPDK，即便在咱们本身的博客上也是如此。我认为这是一个挑战：有机会以稍微不一样的方式讲述数据平面加速的故事。固然，咱们的审查编辑也认为这是一个挑战，由于她正在浏览大量潜在的资料，在个人做品中寻找剽窃的例子。显然，“最诚恳的奉承”在写做界并无价值。

查尔斯·卡莱布·科尔顿(英国做家)

真是惭愧，由于我与说这句话（指上段最后一句）的查尔斯·卡莱布·科尔顿有许多共同之处......不只仅是由于我也逃离了英国，以逃避个人债权人。查尔斯在他的着做《Lacon, or Many Things in Few Words: Addressed to those who think》说：“当追随本身的经验时，错误比无知让本身更难到达终点”。写这样一篇文章的主要缘由是：为了帮助我在前进以前控制个人无知，防止直撞悬崖。另外，咱们网站上的其余页面也欢迎浏览，谢谢。

英特尔做为SR-IOV和DPDK的领导者或直接创始者，都是关于二者的绝佳信息来源。基于AMD（IOV），Inte（VT-d）等的输入/输出内存管理单元（IOMMU）技术的创建和标准化，“单根I/O虚拟化和共享规范”于2007年9月^[1]首次发布，同时服务器虚拟化的概念正在大踏步前进。到目前为止，I/O虚拟化选项是严格基于软件的，虚拟机监控程序（VMM）永久驻留在物理网卡与虚拟网卡（vNIC）之间，vNIC与虚拟机紧密相连。

虽然一般咱们就是这么看待虚拟化机的，并且这确实有一些优点，例如对老旧的应用程序支持和缓解对“专用”硬件的依赖，但使用虚拟机也致使了很是高的CPU利用率。这最终会下降吞吐量和一个平台实际部署的虚拟机数量--在某些状况下，从业务角度来看虚拟化已经再也不可行。

与非虚拟化同样，在虚拟机中处理线缆中的数据包也是中断驱动的。当网卡接收到数据时，会向CPU发送中断请求（IRQ），而后CPU必须停下来去获取数据。任何有孩子的人都会明白，中断是无止境的 - 下降CPU执行主要计算任务的能力。在虚拟机中，这个问题被进一步放大了。运行管理程序的CPU内核不只会被中断，并且一旦识别出该数据包属于哪一个虚拟机（例如，基于MAC或VLAN ID），则必须再向运行该虚拟机的CPU内核发送中断，告诉那个虚拟机来获取它的数据。

这对性能是一个双重伤害，但更重要的是第一个CPU内核是主要的瓶颈，会很快到达最大负载。Intel采起了第一步消除这一瓶颈，并经过被称为虚拟机设备队列（VMDq）的技术来提升总体性能。顾名思义，VMDq使hypervisor可以为每一个虚拟机分配一个不一样的网卡队列。这样以来，不要先向管理程序CPU内核发送中断，只须要中断宿主目标VM的CPU内核。数据包只被搬弄一次，由于它直接复制到VM用户空间内存中。

如今VMDq已经消除了瓶颈，全部VM主机核心中的中断更加平衡。虽然这具备使hypervisor保持在循环中的优势，从而使得诸如vSwitch的功能保持在线，可是以数据平面为中心的虚拟化网络功能中的绝对数量的中断仍将对性能具备使人难以置信的不利影响。这就是SR-IOV诞生的由来。

当SR-IOV诞生时，咱们正在经历一些中断根除运动。 InfiniBand风靡一时，其远程直接存储器访问（RDMA）技术有望推翻IRQs，只要它可以克服以太网。然而，像房子同样，以太网再次证实了这是不该该被打赌的东西。虽然不是“远程的”，由于没有独特的链路层协议，SR-IOV提供的是更加不可知的（读取：以太网）针对DMA的本地化和非overlay方法，专门针对虚拟化^[2]。

源于PCI术语定义的元素把CPU和内存链接到PCI switch fabric (Root Complex)，特别是本身定义名字的port(Root Port)，SR-IOV容许单个的以太网接口表现的像多个独立的物理端口（很像VMDq），用以减轻中断问题，可是，SR-IOV比VMDq更好。

VM 3-ways: Normal operation through bottleneck eradication (VMDq) and interrupt mitigation (SR-IOV)

使用SR-IOV，hypervisor负责为每一个VM实例划分NIC中的特定硬件资源。使人困惑的是咱们全部人仍然试图让咱们的脑壳围绕NFV命名，这些被称为虚拟功能（VFs）。虚拟功能由一个有限的，轻量级的PCIe资源^[3]和一个专用的发送和接收数据包队列组成。在启动时加载VF驱动程序，hypervisor为每一个虚拟机分配这些虚拟功能中的一个。而后NIC中的VF被赋予一个描述符，告诉它所在的具体虚拟机拥有的用户空间内存在哪里。一旦在物理端口上接收到数据包，并将其分类（经过MAC地址，VLAN标记或其余标识符），数据包将在VF中排队，直到它们能够被复制到VM的存储位置中为止^[4]。

这种无中断的操做解放了VM的CPU核心，它就能够更多的被用于本机上的虚拟网络功能的计算。简而言之，SR-IOV很快。事实上，惟一比他更快的是PCI直通技术，可是我忽略了他是由于一次只能有一个VM使用，缘由是PCI设备其实是直接分配给了guest VM。也就是说，和SR-IOV不同，PCI直通技术确实有做为纯软件解决方案的优势，可是他是基于特定的硬件特性（非标准化）。我也忽略了这些优势。

全部这些DMA的好处也是它的缺点，由于接口和虚拟机之间的任何事情都被绕过了。尽管OpenStack的Juno版本扩展了Neutron和Nova以支持网络设备的SR-IOV，从而减小了发生错误的机会，这个数据平面加速选项取决于NFV管理和编排（MANO）层，但DMA技术最终仍是会致使流量绕过Hypervisor vSwitch。这引发了一些问题，包括SR-IOV支持便携性，灵活性，QoS，复杂的业务导向（包括用于服务功能连接的网络服务报头，若是VNF是中间件）的能力以及指望的NFV的云网络虚拟化需求的问题。

一般这并非说你不能在同一台主机上或者你的云环境中同时运行SR-IOV和vSwitch，绝对可行。这将容许NFVI工程师在须要的时候使用vSwitch，SR-IOV或者两种结合使用。SR-IOV对于虚拟化是一个不错的选择，或者用以实施一个单独的虚拟化设备，对于指望得到高吞吐量的VNF设备，路由器或者三层为中心的架构，使用SR-IOV都是很是值得推荐的。而对于以二层为中心的中间设备或者VNF，若是对跨主机的东西向流量有严格的要求，那么就使用vSwitch。可是，这样的混合体系结构可能会增长管理的复杂性，也下降了构建通用，高效和灵活的SDN部署方式的可能性。

先把上面的推测放一边，简单的事实是在NFV基础设施中，咱们在某些地方须要vSwitch。可是vSwitch很慢又笨拙。这并不使人感到惊讶，公平的讲，你们获得了想要的东西--灵活，可编程，状态可维护。但这些都不是没有代价的，这是以牺牲性能为代价的。若是咱们讨论OVS，从如今开始，它尝试引入Megaflow(OVS 1.11 circa April 2011)的概念来提升性能，Megaflow是安装入内核中的二级流表缓存项。

经过把OVS拆分红内核态和用户态两部分，这样以来，一旦在用户态报文被识别并通过处理后，最近被精确匹配转发的数据包对应的Microflow项就经过NETLINK被下发安装到内核中。此外Megaflow每条缓存还包含通配符，能够匹配多个数据包，而不仅是一个。这避免了大量的数据包频繁地与用户态进行IPC通讯，减小上下文切换形成的性能损失。

OVS Circa 1.11, featuring the kernel-level Megaflow Cache together with the Microflow Cache.

可是据称，在OVS 2.1中，这种加强加速显得不太靠谱^[5]。Megaflow的加速能力仍然依赖于数据包的特征和行为和穿越他的流量的模式，所以，不一样的应用会有不一样的结果。简单的说，他可能有效也可能无效--必定程度的不可预测性是不可能被开发和部署到商业服务中的。另外一方面，他依然存在高开销的IPC，这就须要Data Plane Development Kit (DPDK) 大显身手了。

在Megaflow首次亮相（2011年9月）以后没多久，DPDK正式推向了世界，它是一个纯净又简洁的工具包。利用底层英特尔硬件的功能，它包含一组轻量级软件数据平面库和优化的NIC驱动程序，可针对特定应用程序进行修改。领先于6WindGate优化的产品和支持，紧随其后的是另外一个Wind（River，英特尔部门），DPDK在2013年以开源BSD许可证形式向开发社区开放。DPDK能够应用于任何在Intel架构上运行的网络功能，OVS是理想的用例。

DPDK包含内存，buffer，和队列管理，此外还有一个流量分类引擎和一组轮询驱动程序。与Linux新API（NAPI）驱动程序相似，正如咱们从SR-IOV知道的那样，DPDK轮询模式执行全部重要的中断缓解，这对于提升应用程序的总体性能相当重要。在网络流量较大的时候以轮询模式工做，内核会按期检查接口是否有传入数据包，而不是等待中断。为了防止poll-ution(是的，我用来它描述当没有数据须要被获取时的轮询状态)而不至于当有数据包到来时数据包须要等待被接收(这样会增长时延和抖动)，当数据包流量低于某一个阀值时，DPDK能够切换到中断模式。

经过队列，内存和buffer管理器，DPDK还能够经过零拷贝直接把报文DMA到位于用户空间存储器中的大型先进先出（FIFO）环形缓冲区，相似于PF_RING。这又一次显着提升了数据包采集的总体性能，不只能够实现更快的捕获速度，还能够平滑突发的入站流量，使应用程序可以更加一致地处理数据包，从而更高效地处理数据包。 另外，若是客户机CPU忙于处理应用程序，它能够将数据包保留在缓冲区中，而不用担忧这些数据包被丢弃。天然，这个缓冲区大小以及轮询/中断阈值须要对延迟敏感的应用程序（如语音）仔细调优。

The FIFO Ring Buffer

一个开放的vSwitch能够表现一些魔法，可是魔法老是伴随着一个代价，咱们最终在CPU开销中付出了成本。 可是，若是使用修改后的DPDK实现CPU加速，那么CPU开销会大大下降。 那些使用DPDK加速OVS的方法已经实现了独立的控制和数据平面体系结构，这些体系结构在特定CPU内核的用户空间中执行分组处理，以从Linux卸载处理。 实际上，DPDK取代了Linux内核数据平面，这意味着microflows和megaflows都是在用户空间中以相同的方式操做的。

DPDK Accelerated OVS Within User Space

只有复杂的，基于状态的控制和管理协议（即ARP）才被发送到Linux网络堆栈进行处理。 可是，若是将加速的vSwitch与传统的vSwitch实现进行比较，则知足高吞吐量速率的虚拟化网络功能所需的CPU内核数量将大大减小。来自Wind的Charlie Ashton在一年前的博客上发表了一些具体的数字^[6]，一个OVS CPU核心处理0.3M（64字节）pps，须要12个才能支持4 Mpps（或1 Gbps全双工以太网）。即使更多的核心意味着更大的吞吐量，然而主机能够支持的VNF数量也会随之减小。 即便在不利的64字节数据包大小下，Wind的Accelerated vSwitch每一个核心也能处理12 Mpps，所以只须要四个便可将单个全双工10 Gbps接口打满。

HPE最近发布了测试结果，比较裸机与SR-IOV和加速vSwitch的效果，此次是从6Wind^[7]。虽然必须考虑CPU开销，但结果代表，一旦超出64字节的数据包范围，三者的表现都开始与接近高峰的表现大踏步前进。

Data plane acceleration testing results and comparisons, courtesy of HPE

虽然这在表格中看起来不错，但咱们应该记住，典型的Internet Mix（IMIX）流量中的64byte长度的数据包，占平均流量样本的50％到60％。若是有问题的VNF碰巧正在处理实时语音和视频流量，例如会话边界控制器，这将会大大增长。这就是为何咱们将SBC用于SR-IOV和DPDK/OVS测试用例。正如Metaswitch首席技术官Martin Taylor在2015年1月的一篇博客文章中记录的，咱们的结果让人们放心许多^[8]。读了这么多以后，听到SR-IOV仅致使只有几个百分点的性能提升，比咱们行业领先的裸机SBC实施还要少。然而，最使人满意的是，修改后的DPDK OVS达到了SR-IOV的90％的性能。即便经过这种加速的vSwitch方案带来了一些开销，但这也可以理解，毕竟它们有助于部署的灵活性。

若是上面的描述让你觉得SR-IOV和DPDK只能二选一的话，那我得道歉。你固然可使用SR-IOV把数据写入到使用DPDK的虚拟机中。如前所述，您也能够将DPDK加速vSwitch放入主机中，若是从部署的角度来看说的通的话，甚至能够混合使用（和正确的SR-IOV目标VNF加上适当配置的NFV基础架构管理器来处理这种复杂性）。这将仍然有待观察。

因此，感谢Mr.Colton的建议，我学到了什么？或者，更具体地说，我必须“忘掉”什么？我了解到，SR-IOV能够避免不止一个，而是两个中断和一个巨大的性能瓶颈。另外，我发现进程间通讯调用对于vSwitch是多么的有害，并且DPDK将解决喝这个问题。总而言之，我就是这么想的。

原文连接：https://www.metaswitch.com/blog/accelerating-the-nfv-data-plane

相关索引材料

1. Rev 1.1 was introduced in January 2010.

2. iWARP and later RoCE brought true RDMA to Ethernet, in answer to the threat of InfiniBand.

3. The Physical Function (PF - the Ethernet port itself) continues to include a complete PCIe implementation.

4. These are not the physical memory locations, as the VM is unaware of those, so Intel Virtualization Technology for Directed I/O (VT-d) is required to perform the mapping between the virtual address space and the physical one.

5. Andy Hill and Joel Preas from Rackspace at the OpenStack Paris Summit in November 2014.

6. http://www.6wind.com/products/6windgate/optimized-architecture/

7. http://www.slideshare.net/jstleger/dpdk-summit-2015-hp-al-sanders

8. http://www.metaswitch.com/the-switch/tackling-the-nfv-packet-performance-challenge