本文来自对Performance of OVS-DPDK in Container Networks的翻译。
概要——网络功能虚拟化(Network Function Virtualization,VFV)是一种突出的（prominent）技术,用虚拟化的网络软件来代替传统硬件网络节点。伴随着软件领域细分到微服务应用这一过程的发展，容器似乎(appear to)适应了应用程序的可靠性，可获得性，可操作性。为了促进(facilitate)在高稠密(high-denisty)容器环境中IO密集(intensive)应用的发展，OVS和DPDK的联合完美地增加了其性能指标。在本文中，我们在容器网络中设计与集成了OVS-DPDK，被写为两个案例。在第一个案例中，我们在一个物理机器中部署了两个容器并且使用OVS-DPDK作为虚拟网桥来连接它们。在第二个案例中，我们在两个物理机器上配置系统。然后我们测算(measure)吞吐量(throughput),CPU占用率以及评估两个案例中的OVS和OVS-DPDK。
关键词——NFV, OVS, DPDK
1.Introduction近些年，电信工业已经向网络功能虚拟化方向变革(evolve), 传统的“硬件密集型(hardware heavy)”网络节点功能正被虚拟化的能跑在通用硬件(指x86架构芯片)上的软件代替。当前的软件虚拟化的实现(implementation)相比虚拟机正在快速地朝向轻量级的容器[1]。原始的NFV意图沿用软件标准来部署，部署到虚拟机中就称作虚拟化网络功能(Virtualized Network Function, VNF)，部署到容器中就被称作容器网络功能虚拟化(Containerized Network Function)。用高级的容器化技术，CNF能够轻松地在不同的网络设备上被创建，迁移(migrate)，备份和删除，而不依赖特殊的软件。
基于容器技术的快速发展，网络功能(像防火墙，路由器等)被分为许多叫做微服务的块并且每个组件都被连接来创建一个服务功能链来代替已存在的大整块(monolithic)应用。例如，领英在2011年用微服务代替了他们的大整块应用，结果获得了更少的复杂软件并且更短的开发周期(shorter development cycles)。当前，容器网络面对许多挑战去使用这个改变。高密集(high-density)容器会导致建立网络的延迟时间和容器启动时间的消耗(The high-density container causes the latency time to establish its network and time-consuming to container launch time.)
网络功能虚拟化基础设施(Network Function Virtualization Infrastructure)是重要的组件——虚拟交换机。虚拟交换机有在VM之间或者容器之间连接的功能。有许多中虚拟交换机，例如OpenVSwitch(OVS)[4], hyper-V 虚拟交换机[5]，OFSoftSwitch[6], Lagopus[7]等等。我们的实施基于OVS是因为它丰富的特性，多层次，分布式的虚拟交换被广泛地用于主要网络层和其他的SDN应用。OVS传统上已经被分到了一个快速的基于内核的数据路径(datapath, 或者叫 fastpath), 该路径基于流表(a flow table)和一个稍微慢一点的用户空间数据路径，该路径处理在快速路径中。 为了从用户空间转向快速路径，英特尔已经集成了数据平面开发套件(DPDK)到OVS。
DPDK是一个框架，提供了有效的实施，在广泛的一系列一般功能例如网络接口控制器(Network interface controller, NIC)包输入输出， 硬件功能的轻松访问 (easy access to hardware features,例如 SR-IOV,FDIR)等，内存分配和队列。与Linux网络栈比较起来而言，DPDK有突出的特性，那就是能够绕过内核网络栈从而给用户空间的应用带来高性能。DPDK提供了数据平面库，该库优化了网卡驱动，例如轮询模式驱动(Polling Mode Drivers, PMD)用于高速处理，无锁缓存(lockless ring buffers), 大页用于分配和管理内存。开发者能够基于在应用中被打包的库来得到高收益(high achievement)。
通过用DPDK与OVS集成，快速路径也在用户区，最大限度减少了内核与用户空间的交互，同时充分利用了DPDK提供的高性能(By intergrating OVS with DPDK, the fastpath is also in userland, minimizing kernel to userland interactions as well as leveraging the high performance offered by DPDK.)。当前一些文章提到实施DPDK连接VM和VM来提高网络传输性能。在[8]中，作者发展了NetVM平台，该平台利用了DPDK的性能(capability)优势来为"VNF链"获得高性能吞吐。Wang, L.M, Miskell,T[9]使用了OVS-DPDK来抓取和转发(transport)虚拟机的流量。Yang,M.,和Huang,Y[10]比较了部署在物理机器上的OVS-DPDK和部署在Docker容器上的区别，试验台(testbed)环境测试了内部虚拟机的吞吐性能。
在这篇文章中，我们聚焦了设计与集成了OVS-DPDK用于容器网络的两个案例。在第一个案例中，我们在host中部署了容器并且使用OVS-DPDK作为虚拟网桥来连接它们(指容器)。在第二个案例中，我们在两个host中部署了系统，然后我们测算了吞吐量，CPU使用率并且在两个案例中评估OVS和OVS-DPDK。
A.数据平面开发套件(Data Plane Development Kit)
DPDK意图提供简单的和完备的框架用于再数据平面应用中的快速数据包处理。它采取一种“运行时竞争模型用于包处理(run to completion model for packet processing)”, 意为着所有资源需要优先分配到调用数据平面应用。那些专用的资源被执行在了专用的逻辑处理核上。
该技术对应Linux内核，在内核中我们有调度和中断用于切换进程，在DPDK架构中设备进入是通过持续轮询(polling)。这避免了上下文切换和过多的中断而通过CPU和部分的100%占用来处理数据包。
在实践中，DPDK提供了一系列轮询模式驱动(PMDs)，该驱动能够使得数据包在用户空间和物理接口之间直接转发，绕过内核网络栈。该方法提供了重要性能促进内核转发，通过减少中断操作做和绕过内核栈。DPDK是一系列库。于是，为了使用它们，你需要一个应用与这些库连接以及与相关(relevant)API进行关联。
B.OpenVSwitch
OVS 是一个软件交换机，它使包在内核中转发。它由用户空间和内核空间两部分组成:
- 用户空间(User space) - 包括一个数据库(ovsdb-server)和一个OVS守护进程(daemon)用于管理和控制交换机(ovs-switch)
- 内核空间 - 包括ovs内核模式对数据路径或者转发平台负责。
OVS内核模式包含了简单的流表用于转发收到的数据包。仍然，一小部分的数据包被称作例外的(exception)包(在Openflow流中的第一个包)并不匹配一个存在的入口(existing entry)在内核空间并且被发送到用户空间OVS守护者(ovs-vswitched)用于管理控制。守护者进程将会分析数据包然后更新OVS内核流表。因此流上额外的包将会直接通过OVS内核模式转发表。该方法减少了用户空间和内核空间绝大部分流量的上下文切换，然后我们仍然被Linux网络内核栈限制住,内核栈并没有很好的与高速包转发需求相适应。
C.集成DPDK到OVS
集成DPDK到OVS能够大幅提高(leverage)PMD驱动和移动先前的OVS内核模块转发表(OVS kernel module forwarding table)到用户空间。此外，为了促进(boost up)网络容器，vhost-user/virtio-pmd架构被实施到ovs-dpdk。Vhost-user(后端)跑在host的用户空间作为OVS-DPDK用户空间应用的一部分。被提到的DPDK是一个库，Vhost-user模块是库中额外的API。OVS-DPDK是与库和API关联的实际应用。Virtio-pmd(前端)跑在容器上，它是使用特定CPU核以及无中断高性能轮询。对于一个跑在用户空间的应用来说，要去消耗virtio-pmd 就也需要被连接到DPDK。图1展示了这些组件集成到一起。
III.设计和实施在这一节，我们设计实施了CNF和OVS-DPDK在两个案例上并且评估他们。在第一个案例中，我们在host上部署了系统。第二个案例被部署到了两个host上。然后，我们测试来从容器到容器的包转发吞吐量，比较累OVS和OVS-DPDK之间的结果。
我们使用英特尔i5-6300(基础频率2.4GHz，超频3.00GHz带8线程)处理器，6GB内存，英特尔82540EM Gigabit 网卡(1G/s)在每个host上。操作系统为Ubuntu16.04(内核4.4.0)。OVS(版本2.6.1)和DPDK(版本16.11.1)被使用在系统中。
A.Testbed on a single host
数据包被PKtgen[3]和IPerf[11]生成,pktgen是基于DPDK快速包处理框架, iperf是广泛用于各种平台上网络性能测算的工具。为了在容器网络中实施OVS-DPDK, 我们部署了两个由Docker[2]和OVS-DPDK运行的在host用户空间的容器。一个容器有功能产生流量，它被安装了包生成工具。另一个(容器)抓包并且检查性能。每秒钟的吞吐量和CPU利用率被测算。图2显示了实验结果。
图3展示了OVS和OVS-DPDK的平均吞吐量。总体上，吞吐量随着包尺寸增加而增加。OVS吞吐量的增加稳定地(steadily)从104到165Mbits/每秒，同时伴随着包大小从64bytes到1518bytes。在64bytes, OVS-DPDK比OVS有更低的吞吐量因为数据包越小，CPU的消费更大。图4展示了OVS-DPDK比OVS消耗更多的CPU占用率。
B.多个host试验
在第二个案例中，如图5展示， OVS-DPDK和两个容器被部署到两个host中。在该案例中使用的测量单位(metric)与实验1中使用的一样。
图6展示了部署在两个host上的内部容器的平均吞吐量。总体上，在OVS和OVS-DPDK上的吞吐量都在增长。OVS的吞吐量是稳定增长的，从7到17Mbit/s，随着包大小从64到1518byte。同时OVS-DPDK有明显的吞吐量提升。随着包从64bytes到1518bytes, 吞吐量从7到141Mbit/s。与host上的实验相比，吞吐量有了明显增加，因为与第二个案例相比，第一个案例中，所有的连接都被host上的虚拟设备配置了，包没有通过物理连接。
IV.结论
在两个案例中，我们实施了OVS-DPDK用于内部容器网络。在第一个案例中，实验部署在host上，使用了虚拟网络接口和虚拟交换机来连接容器。然而第二个案例用了两个host给内部容器网络。两个案例展示了DPDK相较于原始OVS的突出(outstanding)能力，但是DPDK比OVS更消耗CPU。
即使如此，OVS-DPDK也比原始的OVS具有更高性能，但是它仍然在总体上不是最好的。在未来工作中，我们将扩展和其他技术的实验，例如DPDK与SRIOV和NUMA结合，SRIOV允许一个网卡设备分成多个网卡设备，NUMA用于CPU管理用来获得内部容器网络的高速包处理。
ACKNOWLEDGMENT
(略)
REFERENCES[1] Bernstein, David, “Containers and cloud: From lxc to docker to
kubernetes,” IEEE Cloud Computing 1.3, pp. 81-84, 2014.
[2] https://www.docker.com
[3] Olsson, Robert, “Pktgen the linux packet generator,” Proceedings of the
Linux Symposium, Ottawa, Canada, Vol. 2, 2005.
[4] http://www.openvswitch.org
[5] Hyper-V Virtual Switch project, https://docs.microsoft.com/enus/windows-server/virtualization/hyper-v-virtual-switch/hyper-v-virtualswitch
[6] OFSoftSwitch project, https://github.com/CPqD/ofsoftswitch13
[7] Lagopus switch project, http://www.lagopus.org
[8] Hwang, Jinho, K. K_ Ramakrishnan, and Timothy Wood, “NetVM: High
performance and flexible networking using virtualization on commodity
platforms,” IEEE Transactions on Network and Service Management 12.1
(2015): 34-47
[9] Wang, Liang-Min, et al, “OVS-DPDK Port Mirroring via NIC
Offloading,” NOMS 2020-2020 IEEE/IFIP Network Operations and
Management Symposium, IEEE, 2020.
[10] Yang, Muhui, and Yihua Huang, “OVS-DPDK with TSO feature running
under docker,” 2018 International Conference on Information
Networking (ICOIN). IEEE, 2018.
[11] Traffic generator, https://iperf.fr