服务器中高性能网络数据包处理方法的对比研究

李 霞 李 虎 甘 琤 朱颢东

(郑州轻工业学院计算机与通信工程学院 河南 郑州 450002)

服务器中高性能网络数据包处理方法的对比研究

李 霞 李 虎 甘 琤 朱颢东

(郑州轻工业学院计算机与通信工程学院 河南 郑州 450002)

随着计算机软硬件性能的不断提升，以往只有在通信链路上才能见到的10 Gbit/s、40 Gbit/s数据传输速率，近几年也逐渐出现在服务器集群中。然而，相对于服务器，通信链路上的网络设备使用了不同的指令集和微架构，硬件和系统内核都经过了裁剪。这使得服务器无法像网络设备那样能够快速处理网络数据包。针对这一问题，首先从服务器的硬件结构和操作系统这两个角度分析网络数据包的处理过程，找出在该处理过程中存在的性能瓶颈，并总结相关解决方法。然后将目前较为流行的几个网络数据包处理框架进行对比研究，并分析各自的优缺点。紧接着，通过仿真实验对这些处理框架在不同应用场景下表现出的性能进行验证。最后根据不同处理框架的技术特点给出各自的适用场景和深入研究建议。

服务器 网络数据包 通信链路 Netmap DPDK VPP OVS

0 引 言

诸如软件定义网络、云计算、大数据分析、物联网、社交网络等这些第三方平台的业务，在为企业提供业务流程改造和商业模式转变的同时，也在不断驱动着它们所依托的数据中心网络不断升级和服务器网卡速率的提升。有权威分析指出：到2018年，在数据中心交换机的花费中，超过90%的花费将用于10～40 Gbit以太网[1]。

工作在通信链路上的网络设备大多采用专用集成电路(ASIC)或网络处理器(NP)的方式来实现对网络数据包的快速处理。但是，采用这两种方式需要很长的开发周期才能形成产品，另外还存在开发难度大、灵活性差和扩展性不足等缺点。面对灵活可控的网络管理需求和日新月异的用户需求，越来越多的国内外学者将目光投向了通用服务器解决方案。

近几年，10 Gbit、40 Gbit以太网已经开始出现在服务器上，然而由于CPU性能、PCI-E带宽、内存和操作系统的影响，基于商用多核处理器的服务器很难满足线速处理网络数据的需求。类似的问题早在服务器网卡从100 Mbit/s向1 Gbit/s过渡的时期就曾出现过。当时很多国内外学者发现，在1 Gbit/s的以太网中，利用商用多核处理器和发行版的操作系统难以实现线速捕获网络数据的需求。针对这一问题，专家学者们也相应地给出了一些解决方案[2-5]。此后，针对通用服务器处理网络数据时存在的性能不足，国内外很多学者在硬件优化和软件优化两个方面做了很多深入的研究，并随之出现了许多解决方案(例如：PFQ[5]、OpenOnload[6]、DPDK[7]、Netmap[8]、PacketShader[9]、Snap[10]、NBA[11]等)。这些解决方案可以提升报文捕获、软件路由器、深度报文检测和软件定义网络等这些业务需求在10～40 Gbit以太网中的网络性能。

针对服务器处理网络数据存在性能不足这一问题，本文首先从硬件和软件这两个方面分析了网络数据包的处理过程，选取了目前几个主流的网络数据包处理框架进行对比研究，分析了每个方案的优缺点，并找出了在该处理过程中存在的性能瓶颈和解决方法。然后将目前较为流行的几个网络数据包处理框架进行了对比研究，并分析了各自的优缺点。通过仿真实验对这些处理框架在不同应用场景下的表现出的性能进行了验证。最后根据不同处理框架的技术特点给出了各自的适用场景和深入研究建议。

1 服务器软硬件方面存在的问题及解决方案

目前，大部分的服务器采用了多核的X86架构。在此架构中，从网卡到内存缓冲区的数据传输依靠中断和DMA/DCA来实现，这导致了不可逾越的性能瓶颈。另外，DMA/DCA将网络数据包拷贝到缓冲区后，操作系统需要经过多次内存中的复制和软中断才能将数据传递给用户空间的应用程序，这是另一个重要的性能瓶颈。接下来，本文将从服务器普遍采用的商用多核的硬件结构与操作系统两个方面对可能存在的性能瓶颈进行描述，并对优化方法进行了总结。

1.1 硬件方面存在的问题以及解决方案

处理器在网络数据进行处理所涉及的硬件中，处理器是最重要的一个环节。目前，通用服务器CPU的指令架构大多采用X86架构，不同厂家的CPU以及同一厂家不同系列的CPU又会在微架构和硬件实现上有差别。这些差别会导致当使用不同的CPU处理相同的程序的时候，CPU的运行效率存在很大的差异[12]。衡量CPU运行效率有两个主要的衡量指标：时钟周期和缓存的命中率。文献[13]从CPU的时钟周期和缓存两个角度对网络数据包的处理进行了详细的描述和实验验证。从其推导出的公式fcpu=n(CIO+Ctask+Cbusy)我们可以看出：在处理网络数据包时，CPU的开销主要由IO总线传递数据占用的开销CIO、CPU处理数据的开销Ctask和CPU处于忙时的开销Cbusy三部分组成。在缓存的命中率方面，由于CPU采用了超标量、乱序执行、分支预测等技术，这使得缓存的命中率可以接近1。另外，根据处理器的优化方式，我们可以将现有的优化方案分为两大类：基于CPU微架构的优化方案[14-15]和基于CPU+协处理器优化方案。基于CPU微架构的优化方案不具有通用性，而基于CPU+协处理器优化方案主要分为采用GPU作为协处理器的方案(PacketShader、Snap、NBA)和采用FPGA作为协处理器的方案(DAG[16]、NetFPGA SUME[17]、NPDK[18])。

总线总线是影响网络数据处理性能的另一个重要因素。主要涉及CPU的内部总线和PCI-E总线。内部总线主要用于CPU内各部件之间的信号和数据的传递。自2010年，Intel Xeon®系列的内部总线开始使用4条独立的环形总线结构[19]，每条环可以提供25.6 GB/s的峰值带宽，同时内存控制器和PCI-E控制器也被集成到了CPU上。理论上，采用PCI Express 2.0 x8的设备双向传输的有效带宽为32 Gbit/s，而采用PCI Express 3.0 x8的设备双向传输的有效带宽约为63 Gbit/s。以一个使用PCI-E 2.0 x8接口的万兆网卡举例，如果一张网卡上的网络接口数量为两个的时候，这张网卡的吞吐率将会达到40 Gbit/s，显然有效带宽只有32 Gbit/s的PCI Express 2.0 x8接口将会成为瓶颈。

内存从硬件方面考虑内存的瓶颈，主要从内存的亲和性和内存的带宽两方面考虑。内存带宽通常不会是造成处理网络数据的瓶颈，因为在常见的DDR3和DDR4中，即使DDR3中最慢的速度也能达到51.2 Gbit/s。内存亲和性则有可能成为性能瓶颈。内存亲和性是指内存控制器被移到CPU内部之后，在多个NUMA(Non-Uniform Memory Access)节点并存的情况下，本节点内的设备应尽可能地访问本节点的内存，跨节点访问内存会造成数据所经过的多个NUMA节点的IO性能下降。文献[9]对跨NUMA节点的内存访问进行了测试，结果表明跨节点的内存访问会导致带宽利用率下降20%～30%，进一步导致访问时间会增加40%～50%。

网卡目前大多数的10 Gbit/s、40 Gbit/s网卡采用PCI Express 2.0或PCI Express 3.0的标准。另外，很多网卡提供硬件多队列的支持，RSS(Receiver Side Scaling)技术就是一种通过哈希函数对IP五元组的值进行处理，然后根据处理结果将不同的数据包交给不同的硬件队列。 Linux内核自2.6.21版本之后就开始支持这一功能。

1.2 软件方面存在的问题以及解决方案

Han[9]，Gallenmuller[13]，Liao[15]，Emmerich[20]等均对Linux处理网络数据包时所占用CPU的时钟周期进行过测试，这些测试结果均反映出：网卡驱动程序、数据包缓冲区的管理方式、操作系统协议栈这些环节都会占用大量的CPU时钟周期。

驱动程序现有的网卡驱动程序大多采用环形队列的方式管理数据包缓冲区。当网卡驱动程序加载的时候，多个环形队列就会被提前准备好，当队列中的数据包被传输出去之后，空闲的存储空间又可以被重复使用。这种环形队列管理方式相对于为每个数据包单独分配存储空间的方式避免了不必要的开销。为了提高处理网络数据的性能，在Linux内核版本中，自2.6版本之后，NAPI[23]技术成为了提升处理网络数据的性能的一个主要方法。这种技术使用中断与轮询的方式，解决了每当有网络数据包到达时都要触发中断从而影响操作系统性能的问题，取而代之的是每次中断都会以批处理的方式处理数据包，从而分摊了这一部分的CPU开销。UIO[24]技术同样是一种用于提升处理网络数据性能的技术，这是一种将环形队列数据映射给用户空间应用程序的技术。因为它仍然在内核空间驻留了少量代码，所以这一做法并不会对系统的稳定性产生太大的影响。

多次数据拷贝网络数据包被写入环形队列后，需要经过内存之间的拷贝才能从环形队列进入内核空间的数据缓冲区，同样需要经过内存之间的拷贝才能从内核缓冲区进入用户空间的内存区域。根据数据包长度的不同，每次内存之间的拷贝都要消耗500～1 200不等的CPU时钟周期[15]。在这一部分CPU时钟周期中，二级缓存未命中导致的损耗占50%，共享缓存未命中导致的损耗占27%，指令的执行周期占20%。在文献[9]中也得出了类似的结论。数据拷贝产生的瓶颈可以通过内存映射的方法解决：将环形队列的内存区域映射给用户空间的内存区域，或将存储网络数据包的内核缓冲区映射给用户空间的内存区域。显然前一种方法比后一种方法少了一次内存拷贝，缺点是将环形队列和网卡寄存器暴露给了用户空间的应用。文献[8]认为这将会影响系统的稳定性，但是，文献[18-21]认为所有的解决方案向用户空间应用提供的软件接口会起到保护的作用。

操作系统协议栈操作系统中的用户态进程需要调用协议栈提供的Socket接口才能进行正常的网络通信。由于调用内核协议栈需要频繁的CPU上下文切换，因此这种方法在占用大量的开销的同时，还会导致CPU中cache的命中率下降。操作系统协议栈中包含了大量的网络协议层的协议，完善的协议栈保证了数据可以可靠地交付给用户态进程的同时，还占用了大量的CPU开销。最后，操作系统的协议栈需要通过拷贝的方式才能将数据包从内核空间的内存区域传递到用户态的内存区域，这一过程同样占用了大量的CPU开销。文献[2,11]中的解决方案大多绕开了操作系统协议栈，这就造成了基于操作系统协议栈的应用程序必须经过移植才能使用这些解决方案。替代的方法是将协议栈移置用户空间，这样可以大量减少内存拷贝和CPU开销。文献[25]的研究表明，在TCP连接数量到达8 000个的时候，内核协议栈拷贝数据的耗时量是用户态的协议栈耗时量的55～145倍。

中断平衡在使用了多核CPU的操作系统中，会存在中断平衡的问题。当网卡的中断被频繁切换的时候，会导致CPU的缓存命中率下降，从而影响处理网络数据的性能。正如上文分析内存时指出的，在多个NUMA(Non-Uniform Memory Access)节点并存的情况下，同一个节点内的设备应尽可能地访问本节点的内存。同理，应该尽可能使用相同NUMA节点中的CPU和内存处理网卡的数据，甚至应该尽可能使用相同节点中的同一个CPU内核处理网卡的同一个队列的数据。

大页内存这种技术可以减少TLB(Translation Look aside Buffer)的未命中以及减少虚拟内存地址和物理内存地址之间的转换多带来的开销。大页内存技术尤其适合内存消耗巨大、内存访问随机和存在内存访问瓶颈这些情况。文献[7,11]使用了这种技术优化了访问内存时候的开销。

2 相关软件优化方案与硬件优化方案

基于研究结果是否可以复现这一考虑，本文挑选了5种完全开源的方案：DPDK、Netmap、Snap、NBA和PFQ。那些需要付费、不便于复现的研究[9]，以及不具有通用性的研究[6,14-18]不在本文的考虑范围之内。表1对比了这些方案的技术特征。

表1 优化方案的技术特征

DPDK：它是Intel官方推出的一款数据平台开发工具箱，由多种功能的函数库组成。函数库涵盖驱动、内存、计时器、锁、协议栈等多方面的开发需求。DPDK使用了UIO技术，用于将网卡缓冲区映射给用户空间应用程序。因为它绕开了操作系统的内核，所以工作在操作系统协议栈上的应用程序无法直接使用它。另外需要指出的是它提供了虚拟化的功能，这使得它可以提升Open vSwith和OpenFlow switch中数据包的处理性能。

Netmap：它是一种采用了优化环形队列的结构、内存映射、批量处理、绕开系统内核等多种技术的数据包处理框架。首先，Netmap将网卡环形队列中的数据拷贝到了内核空间中的共享内存；接着，当没有程序调用Netmap的API的时候，Netmap管理的共享内存将和操作系统协议栈交换数据，当有程序调用Netmap的API的时候，Netmap管理的共享内存直接和应用程序交互数据，同时会拷贝一份数据给操作系统协议栈。通过这种方法，操作系统不会意识到任何的改变，仍然可以正常管理网卡[8]。Netmap提供有API的同时还提供了libpcap接口，使得基于libpcap的程序可以利用Netmap提高自身的性能。另外，Netmap还可以运行在Windows和FreeBSD环境中，尤其是FreeBSD已经将Netmap集成到了内核中。在虚拟化环境中，它可用于提升Qemu/kvm、Click和VALE等软件处理数据包的性能。

Snap：这是一种使用了Netmap和Click的数据包处理方法。它解决了Click并发性能不足的问题，为Click增加了使用GPU处理数据包的模块。Snap处理数据包的过程：首先，在将Netmap控制的内存中的数据拷贝给Click控制的内存区域之前，Snap通过给每个进程增加一个数据包缓冲区的方法解决了Click并发性能不足的问题，另外，还通过将Click的数据包处理进程绑定给不同的CPU内核的方法解决了Click的CPU缓存命中率低的问题。其次，Snap通过增加Click模块的方法解决了主机内存与设备内存之间数据拷贝的问题。最后，Snap通过数据包切片(即处理每个数据包的部分内容)的方法节约了该处理方案对内存和PCI-E带宽的占用量。由于没有解决好数据包分歧(packet divergence)的问题，Snap方案中存在多次内存之间的数据拷贝，这使得Snap处理小包的性能不足。从其SDN转发结果可以看出：包大小为64 Byte时，每个10 Gbit/s速率的接口使用CPU处理的转发速率约为8.79 Mpps；使用GPU处理的转发速率约为12.21 Mpps；只有进一步对数据包切片后，使用GPU处理的转发速率约为14.65 Mpps。

NBA：这是一种使用了DPDK和Click的数据包处理方法，解决方法与Snap类似。不同的是该方案还提供了负载模块，它允许在CPU和GPU之间进行负载调度。另外，它还采用了批量拷贝和批量处理的方法来缓解内存拷贝带来的开销。尽管这些改进可以帮助NBA提升处理数据的性能，但是，在NBA处理数据的过程中同样存在多次内存拷贝的问题。这使得它也不能满足线速处理数据包的需求。

PFQ：这是一种不需要改动网卡驱动程序就能实现对Linux环境下网络数据包处理进行优化的解决方案。PFQ在内核中增加了内核模块，该模块通过内存映射的方法将网卡中的数据分发给不同的PFQ队列，不同队列的数据又会传递给各自的Socket和用户空间程序。然而，正是因为PFQ没有绕开内核协议栈，这使得网卡的环形队列中的数据不可以直接传递给用户空间的应用程序，从而影响了该方案在处理数据包时的性能。

在这5种解决方案中，DPDK、Netmap和PFQ属于纯软件的解决方案，用于解决数据包在网卡缓冲区与用户态进程之间传输性能低的问题。由于DPDK和Netmap对处理数据包时存在的问题解决得更彻底，这使得它们可以满足线速处理数据包的需求。而Snap和NBA属于软件和GPU结合的协处理器解决方案，而且都是在已有的软件方案基础上利用GPU处理数据包的解决方案。但是，由于Snap和NBA在处理数据的过程中都存在多次内存拷贝的问题，使得它们不能满足线速处理数据包的需求。

3 测试与验证

针对不同解决方案适用的场景不同，接下来，本文将从Linux网络性能优化、报文捕获和云计算这三个应用场景，对Linux环境中多种数据包处理方案进行对比研究。通过仿真实验对这些方案进行了验证，所有的仿真实验都遵循RFC2544[26]标准。实验环境中每台服务器包含两个NUMA节点，每个节点中的CPU型号为Intel Xeon E5-2620，内存类型为DDR4-2133 MHz，PCI-E插槽类型为PCI-E 3.0，网卡型号为Intel X510-SR2，操作系统为Ubuntu-16.04.1-server。在该仿真环境中，发包软件为Pktgen-dpdk-3.1.0，它使用双队列就可实现报文长度在64～1 518 Byte范围内的线速发包。

3.1 应用场景1：Linux的网络性能优化

由于现有网络数据包处理方案大多绕过了操作系统的网络协议栈，因此，这些方案无法直接为运行在操作系统协议栈之上的网络应用提高性能。然而，除了操作系统的协议栈，服务器中影响网络性能的因素还有很多，主要有硬件的特性、驱动程序的参数、内核参数和开启的网络功能等。因此，该场景的实验无法逐一对这些影响因素进行对比研究。在使用相同型号硬件和相同操作系统版本的情况下，该场景使用清单1的优化方法对操作系统的网络性能进行了优化，在图1中对比了优化前后的结果。

图1 Linux系统的网络优化前后的吞吐量

测试环境的优化内容：

检查CPU内核所属的NUMA节点

lscpu

检查每个网卡的PCI总线地址

lspci | grep Ethernet

检查网卡所属的NUMA节点

cat /sys/bus/pci/devices/0000…XX…XX.X/

numa_node

在网卡所属的NUMA节点中隔离CPU内核

iommu=pt intel_iommu=on isolcpus=0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30

关闭操作系统的irqbalance服务

/etc/init.d/irqbalance stop

依次调整所有隔离出来的CPU内核工作频率

echo performance>/sys/devices/system/cpu/cpuX/

cpufreq/scaling_governor

使用ixgbe驱动时，调整网卡队列数量

echo 0 > /sys/devices/system/cpu/cpuX/online

rmmod ixgbe

modprobe ixgbe

关闭影响网卡接收性能的功能

ethtool-K eth0 gro off lro off rx off

调整网卡的环形队列的长度

ethtool-G eth0 rx 4096

设置网卡的MTU以减少每个帧的开销

ifconfig eth0 mtu 1500

清单1给出了在相同的硬件与操作系统的测试环境下，如何通过调整网卡与CPU的亲和性优化NUMA节点内的数据传输的效率。同时还给出了通过隔离CPU和关闭中断平衡的方法，保证了不相关的进程无法使用被隔离出的CPU，从而避免了网卡队列的中断频繁在不同的CPU内核之间切换的问题。另外，通过关闭接收队列的数据包聚合、关闭流量控制的功能、增加接收队列的长度和调整MTU大小等一系列的方法，提高了网卡的接收效率。

从图1的对比结果可以看出：在对操作系统的网络优化之前，操作系统处理小包的吞吐量较低。经过优化，尽管操作系统处理小包的吞吐量明显上升，但是在处理报文长度小于512 Byte的时候，吞吐量仍然无法达到10 Gbit/s。

对于那些在Linux环境中对小包处理较为敏感的网络应用，在优化网络性能的时候，建议从网卡所属的NUMA节点中挑选出若干CPU内核，专门用于处理网卡中的数据。这样有助于提升这些应用处理小包的性能。

3.2 应用场景2：报文捕获

在该应用场景中，发包方保持每个报文长度为64 Byte不变并以14.88 Mpps的速度发包；接收方则采用图1的方法对测试环境进行了优化，以保证在相同的环境中，每种方案都能发挥出最佳的性能。测试对象为包括DPDK、Netmap、PFQ和libpcap在内的4种方案。通过改变每种方案的接收队列数量，测得了以上4种方案的丢包率，结果如图2所示。

图2 报文捕获场景中的丢包率

该场景中的DPDK和PFQ支持通过参数的方式调整队列，而Netmap和libpcap则不可以。该实验通过CPU下线并保留与队列数量相同的CPU数量的方式，达到了在实验中调整队列数量的目的。

从图2的实验数据上可以看出：当发包方持续以14.88 Mpps的速度发包的时候， libpcap和PFQ的丢包率较高，DPDK和Netmap则一直保持着较低的丢包率。随着队列数量的增加，所有方案的丢包率均有小幅的波动。而DPDK在队列数量达到10的时候，丢包率的波动幅度减少，并且丢包率持续下降，直至队列数量达到16的时候，丢包率接近于0。

在那些对网络报文捕获率有较高要求的应用场景中，建议利用DPDK或Netmap作为底层框架进行二次开发。DPDK拥有较为完整的开发文档和活跃的技术社区，而Netmap可以平滑地升级那些基于libpcap开发的应用。

3.3 应用场景3： 云计算与软件定义网络

在云计算和软件定义网络中，通常使用OVS(Open vSwitch)处理网络数据包的转发。但是原生的OVS存在吞吐量较低，处理延迟较大等问题。自版本2.2开始，OVS分别从物理网卡和虚拟网络两方面支持使用DPDK优化OVS的数据包传递性能。类似OVS的软件还有VPP(Vector Packet Processing)，该软件也可以使用DPDK进行性能优化。该实验中，发包方使用不同的数据包长度依次进行发包。收包方同样先采用图1的方法对OVS(v2.6.1)和VPP(v17.04-rc0)的测试环境进行了优化，然后在统一了接收队列数量和队列长度的基础上，测得了两种软件的转发速率，结果如图3所示。

图3 OVS与VPP的转发速率

从图3的实验数据上可以看出：VPP和OVS的转发性能，在整体上表现出了较为相似的结果，尤其是在报文长度大于256 Byte之后，均接近了线速转发。主要原因是两种软件都使用DPDK方案处理网卡和用户空间程序之间的数据流。但是在报文长度小于256 Byte的时候，两种软件的处理小包的性能展现出了明显的不同。无论是处理物理网卡之间的二层转发和处理物理网卡与vhost-user虚拟网卡之间的二层转发，VPP表现出来的性能都优于OVS。另外，两种软件处理物理网卡之间的二层转发的性能优于使用虚拟网卡vhost-user做二层转发的性能。由于OVS自身不支持三层转发，该实验仅测得了VPP的三层转发速率。

在那些对数据转发有严格要求的VPP和OVS的应用场景中，建议尽量使用物理网卡实现二层转发。在VPP和OVS环境中，尽管经过DPDK优化后的虚拟网卡vhost-user表现出了很高的转发性能，但是在虚拟机中仍然存在处理数据的瓶颈。这使得在虚拟机中使用vhost-user虚拟网卡提升网络性能的效果不明显。

4 结 语

对服务器处理网络数据性能不足这一问题的研究目前是计算机网络领域的一个研究热点，本文中对比研究的这些网络数据包处理方案，大多长期保持持续更新的状态。尤其是DPDK和Netmap两种方案，已经开始应用于与之相关的研究课题。特别是在云计算与软件定义网络中的应用，由于DPDK的性能优异，使得VPP和OVS的转发速度可以接近线速。但是，由于传统网络应用程序无法直接使用这些解决方案提升自身的网络性能，这一原因造成了这些解决方案目前无法广泛应用于提升服务器处理网络数据包的性能。另外，相对于内核协议栈，虽然用户态的协议栈已经在一定程度上解决了协议栈处理数据包时存在的问题，但是它仍然存在小包处理速度慢和其他用户态进程无法直接使用等问题。解决好这些问题对于提升操作系统的整体网络性能将具有重要的意义。

[1] Brad Casemore,Petr Jirovsky,Rohit Mehra.The New Need for Speed in the Datacenter Network[R].IDC Technology Spotlight,2015.

[2] Deri L,Via N S P A,Km B,et al.Improving passive packet capture:beyond device polling[J].Proceedings of Sane,2004.

[3] Gibb G,Lockwood J W,Naous J,et al.NetFPGA—An Open Platform for Teaching How to Build Gigabit-Rate Network Switches and Routers[J].IEEE Transactions on Education,2008,51(3):364-369.

[4] 刘峰.Linux环境下基于Intel千兆网卡的高速数据包捕获平台的研究[D].厦门大学,2008.

[5] Bonelli N,Pietro A D,Giordano S,et al.On Multi-gigabit Packet Capturing with Multi-core Commodity Hardware[C]//International Conference on Passive and Active Measurement,2012:64-73.

[6] Solarflare.Openonload[EB/OL].2008.http://www.openonload.org/.

[7] Intel.Intel DPDK:Data Plane Development Kit[EB/OL].2013.http://dpdk.org/.

[8] Rizzo L.Netmap:a novel framework for fast packet I/O[C]//Usenix Conference on Technical Conference.USENIX Association,2012:9-9.

[9] Han S,Jang K,Park K S,et al.PacketShader[J].Acm Sigcomm Computer Communication Review,2010,40(4):195.

[10] Sun W,Ricci R.Fast and flexible:Parallel packet processing with GPUs and click[C]//Architectures for Networking and Communications Systems (ANCS),2013 ACM/IEEE Symposium on,2013:25-35.

[11] Kim J,Jang K,Lee K,et al.NBA (network balancing act):a high-performance packet processing framework for heterogeneous processors[C]//Tenth European Conference on Computer Systems.ACM,2015:1-14.

[12] Braun L,Didebulidze A,Kammenhuber N,et al.Comparing and improving current packet capturing solutions based on commodity hardware[C]//ACM SIGCOMM Conference on Internet Measurement 2010,Melbourne,Australia-November.DBLP,2010:206-217.

[13] Gallenmuller S,Emmerich P,Wohlfart F,et al.Comparison of frameworks for high-performance packet IO[C]//Eleventh Acm/ieee Symposium on Architectures for Networking & Communications Systems.IEEE,2015:29-38.

[14] Binkert N L,Saidi A G,Reinhardt S K.Integrated network interfaces for high-bandwidth TCP/IP[J].Acm Sigplan Notices,2006,34(5):315-324.

[15] Liao G,Xia Z,Bnuyan L.A new server I/O architecture for high speed networks[C]//High Performance Computer Architecture (HPCA),2011 IEEE 17th International Symposium on.IEEE,2011:255-265.

[16] Endace,Capture network packet device[EB/OL].2016.http://www.endace.com/endace-dag-high-speed-packet-capture-cards.html.

[17] Zilberman N,Audzevich Y,Covington G A,et al.NetFPGA SUME:Toward 100 Gbps as Research Commodity[J].IEEE Micro,2014,34(5):32-41.

[18] Lu T,Yan J L,Sun Z G,et al.Towards high-performance packet processing on commodity multi-cores:current issues and future directions[J].Science China Information Sciences,2015,58(12):1-16.

[19] Park C,Badeau R,Biro L,et al.A 1.2 TB/s on-chip ring interconnect for 45nm 8-core enterprise Xeon®processor[C]//Solid-State Circuits Conference Digest of Technical Papers.IEEE,2010:180-181.

[20] Emmerich P.Assessing Soft- and Hardware Bottlenecks in PC-based Packet Forwarding Systems[J].Computation World,2015:78-83.

[21] García-Dorado J L,Mata F,Ramos J,et al.High-Performance Network Traffic Processing Systems Using Commodity Hardware[M].Data Traffic Monitoring and Analysis,2013:3-27.

[22] Intel.Design considerations for efficient network applications with Intel®multi-core processor-based systems on Linux[EB/OL].2010.http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/multi-core-processor-based-linux-paper.pdf.

[23] The Linux Foundation,NAPI[EB/OL].2016.https://wiki.linuxfoundation.org/networking/napi.

[24] Corbet.UIO:user-space drivers[EB/OL].2007.https://lwn.net/Articles/232575/.

[25] Jeong E Y,Woo S,Jamshed M,et al.mTCP:a highly scalable user-level TCP stack for multicore systems[C]//Proceedings of the 11th USENIX Conference on Networked Systems Design and Implementation.USENIX Association,2014:489-502.

[26] Bradner S.Benchmarking Methodology for Network Interconnect Devices[S].RFC 2544,1999.

COMPARATIVERESEARCHONHIGH-PERFORMANCENETWORKPACKETPROCESSINGMETHODSINSERVERS

Li Xia Li Hu Gan Cheng Zhu Haodong

(SchoolofComputerandCommunicationEngineering,ZhengzhouUniversityofLightIndustry,Zhengzhou450002,Henan,China)

With the improvement of computer software and hardware performance, the data transmission rate of 10 Gbit/s and 40 Gbit/s can only be seen on the communication link in the past. In recent years, it has gradually appeared in the server cluster. However, with respect to the server, the network device on communication link uses a different set of instructions and microarchitecture, the hardware and the system kernel have been clipped, which makes it impossible for the server to process network packets as quickly as a network device. To solve this problem, this paper firstly analyzed the process of network packet processing from the two aspects of the hardware structure and operating system of the server, and found out the bottleneck and summarized relevant solutions. Secondly, a comparative study was made on several popular network packet processing frameworks, and their advantages and disadvantages were analyzed. Subsequently, the performance of the framework was verified by simulation experiments under different application scenarios. Finally, according to the technical characteristics of the different processing framework, the respective application scenarios and suggestions were put forward.

Servers Network packet Communication link Netmap DPDK VPP OVS

2017-01-17。李霞，教授，主研领域：计算机网络，数据挖掘。李虎，硕士生。甘琤，讲师。朱颢东，副教授。

TP301

A

10.3969/j.issn.1000-386x.2017.11.033