基于DPDK混合中断轮询模式的报文传输框架

赵欢欢，张根全，张惠鑫

(1.中国电子科技集团公司第五十四研究所，河北 石家庄 050081；2.河北广电信息网络集团股份有限公司石家庄分公司，河北 石家庄 050000)

0　引言

随着Hippi和ATM等高速网络交换技术的应用，具备高效率、低消耗等优点的机群系统[1-2]已成为实现并行计算的主流技术。CPUs、GPUs异构计算模型[3-5]的提出，更使得机群系统中单节点计算能力得到了极大提高。但是高速局域网络技术提供的Gb级带宽的物理链路，却由于linux等操作系统在协议栈的实现效率无法满足链路传输要求，导致单节点机最大可以处理的数据量只达到百Mb级，节点间网络通信开销成为影响计算性能的制约因素。因此设法提高通信传输速率对于提高整个机群系统的并行计算能力具有重要意义。

目前，提高网络传输速率的方法大多基于以下两方面：① 降低中断开销，尽量使用轮询的方式一次处理多个数据包，如NAPI技术[6-7]已在linux当前版本的系统内核中使用；② 内存零拷贝的方式[8]，减小内核到用户空间的包复制，如netmap框架[9-11]。此外，著名的PF-Ring框架[12-13]结合两个方面，具有极高的性能表现。但linux的分时处理机制带来的系统调度会对性能带来负面影响，同时上述方案没有发挥CPU多核的优势。

1　报文传输技术体制

目前应用广泛的典型网络传输框架有基于系统内核层的Libpcap和基于用户态处理的PF-Ring框架，近两年DPDK技术随着开源而高速发展，本节对其进行分析对比。

1.1　Libpcap

传统的网络节点获取报文大多采用基于TCP/IP 协议栈的函数库Libpcap[11]，它是一个独立于系统的用户层包捕获的API接口，利用内核层网络协议栈处理底层通信。但是报文传输过程中因操作系统低效的网络协议构架导致频繁的上下文切换、系统调用以及数据拷贝等开销，造成其低下的通信性能无法适应大规模机群系统的通信需求.。

1.2　PF-Ring

PF-Ring[12-13]是Luca设计的基于Linux内核级数据包处理框架，核心思想是通过旁路了操作系统，将网卡接收到的数据存储在环状缓存区内，由用户应用直接从环状缓存区读取数据。

PF-Ring支持3种工作模式，工作模式1、2的效率较高。其中，框架工作模式1使用TNAPI技术[13]，利用多线程同步轮询网卡接收队列，复制数据到内核层缓存，使用DMA均衡到各个CPU核，利用多核提升性能。但由于数据包捕获及预处理仍在内核层完成，与用户层数据交互会增加反复调度的性能消耗，同时TNAPI技术为提高数据包的捕获，发送队列被禁用。框架工作模式2使用网卡网络处理单元直接从网卡数据映射到DMA环形缓存，比模式1提高了性能，但是一次只能由一个应用使用DMA环形缓存，对多连接情况需同步不同的应用。硬件方面，要求更改网卡驱动，存在支持的第三方网卡驱动有限且网卡驱动稳定性无法保证等问题。

1.3　DPDK技术

DPDK[14](Intel Data Plane Development Kit)是Intel提供的数据平面开发工具集，其核心组件由一系列用户层上的数据包处理库函数和驱动组成，为高性能数据包处理提供基础操作。内核层模块主要实现轮询模式的网卡驱动和接口，并提供PCI设备的初始化工作；用户层模块则提供大量给用户直接调用的函数。

DPDK通过环境抽象层旁路内核协议栈，同时采用多项技术，实现了在x86处理器架构下的高性能报文处理能力。这些技术大致归为：① 轮询，可避免中断上下文切换的开销；② 用户态驱动，既规避了不必要的内存拷贝，又避免了系统调用；③ 亲和与独占，利用线程的CPU绑定，避免线程不同核间频繁切换带来的开销；④ 降低访存开销，采用内存大页降低TLB miss，内存多通道交错访问提高内存访问带宽等。

但是，与使用Linux内核的应用框架相比，数据包将不再通过内核，而通过DPDK的专用路径，从网卡直接拷贝到用户空间，交由用户应用处理，所以使用DPDK后，无法再使用系统内核协议栈，而DPDK本身并不具备协议栈的功能，因此用户需要自己设计/实现用户态网络协议栈。

2　基于DPDK的报文传输框架设计

2.1　框架设计思路

如图1所示，本框架是一个linux系统上的多核加速数据传输解决方案，运行在多个核上，为上层应用提供高性能的网络数据通道。

图1　传输框架架构

多核并行计算中，通常采用多进程/线程实现。在传统多进程/线程的编程中，锁是保证数据安全的重要手段。由于资源的竞争,进程/线程不得不阻塞等待。据实验测试，一个高并发的应用，20% ～70%的时间可能耗在无谓的锁等待上。

因此，采用基于分片的设计，使每一个核对应一个线程，每个核有独占的资源：CPU、内存、网络。多核之间没有数据共享、锁等需要阻塞同步的操作，保证多核间操作的异步性，从而达到高性能和低延迟的目标。由于多核间没有资源的竞争，随着核数量的增加，扩展性和性能也会随之提升。

鉴于DPDK为底层处理和I/O数据包提供硬件处理功能，本框架提供了一套在DPDK之上的数据处理、网络堆栈实现和应用支撑接口等功能的工具包。其中：① 数据接收模块采用基于状态的混合终端轮询模式加速数据接收，并提供了数据过滤操作；② 网络协议模块中高度模块化网络堆栈，并在单线程环境下优化原网络层服务和功能，以及应用层需要的TCP/UDP协议[15]处理，解析网络栈按需要可配置，指定加载全部或部分功能特性；③ 接口适配模块提供了socket及链路层数据接口，供上层不同应用选择。

2.2　基于状态的混合中断轮询机制

由于机群系统中可能存在潮汐效应，大部分时间处于平稳的高流量状态，中断方式会使操作系统陷入中断频繁响应环节，产生的消息处理开销影响系统的处理性能；某段时间网络数据流量可能很低或无数据传输，轮询方式就会出现高速端口下低负荷运行，加重CPU 的负载。

针对上述情况，一种比较好的实现方法就是采用混合中断轮询驱动进行传输控制。该机制结合了中断与轮询，高负载情况下轮询操作保证了数据不丢包，而低负载情况下中断保证CPU的其他计算工作，从而很好地平衡延迟与吞吐量要求。

根据混合中断轮询驱动机制得到的有限状态机模型如图2所示。

图2　状态机模型

其中：

① 系统开中断状态下的初始状态转变为关中断的轮询状态，并配置的滑动窗口尺寸W，初始化轮询滑动接收报文个数R；

② 若R>W，说明吞吐量接近或达到平衡状态，则继续轮询模式；

③ 若R

④ 单位时间中断量大于阀值时，进入轮询模式；

⑤ 单位时间中断量小于阀值时，继续中断模式；

⑥ 内存耗尽，过渡到初始状态后，进行①。

2.3　报文处理过程

报文传输处理中，旁路了操作系统，由框架直接读取网络链路层数据，并由用户层协议栈实现报文的解析、组包等处理操作。轮询状态下，框架接收线程不间断读取网卡数据；中断状态下，框架接收网卡中断信号后，唤醒接收线程进行数据读取。流程如图3所示。

其中：

① 基于分片的设计，使得框架会对每个核进行资源分配，每一个线程分配一个核；

② 对预分配给框架的物理内存进行分片，每个核占有独立的内存空间，独立完成对内存区域的分配和释放管理；

③ 每个核与物理网卡的一个接收队列和发送队列进行绑定(数据连接也被分片)，每个核只处理各自负责的连接；

④ 中断状态下， 接收线程始终处于睡眠状态，每当网卡产生中断信号，随即唤醒接收线程，进行数据读取操作，至用户层环形缓存后进行处理；

⑤ 轮询状态下，接收线程始终处于激活状态，不间断直接读取接收队列数据到用户层环形缓存后进行处理；

⑥ 数据经协议栈封装后，通过DPDK直接向网卡发送。

图3　报文处理流程

3　试验验证

为了对本框架(DPDK+TCP/IP)进行性能分析，与专用数据发送服务器采取光纤连接的方式对所实现的实例进行了性能测试。测试在普通商用服务器(CPU：Xeon E5 4核，2颗，主频3.50 GHz；内存：16 G；操作系统：Red Hat Enterprise Linux Server 6.5)，使用万兆网卡Intel 82599进行。

接收端接收报文后统计，半小时不丢包则增大流量，直到网卡满负荷或丢包，测试包长从64～1 500 Byte，测试丢包率为0的情况下的最大包处理速率与网络带宽使用情况。

为了极限利用网络带宽，在网络处理的整个流水线上(即数据包的整个生命周期中)，不能有任何一级流水处理延时超过报文间的时间间隔，因此数据包越小，挑战越大。试验结果如图4和图5所示，DPDK由于在高速网络传输中不再产生中断，在包大小大于256 Byte后，包接收速率基本达到理论值。而PF-RING因为需要一定量的软中断处理，消耗了处理时间，包大小大于512 Byte后，包接收速率才接近理论值。

图4　包速率对比结果

图5　通信带宽使用对比结果

由图4和图5可知，本框架(DPDK+TCP/IP)在包报文处理速率上明显优于PF-RING+TCP/IP和Libpcap，主要是充分利用DPDK技术提高数据接收速率，同时在用户层协议解析过程中，不需要锁等同步处理。而PF-RING+TCP/IP虽然采用DNA技术，将网卡数据映射到DMA环形缓存，但对该数据处理时需要同步操作，消耗了流水时间；至于Libpcap使用的内核级处理，过多的中断响应降低了效率。

4　结束语

本文对典型的报文传输框架进行了分析，设计并实现了一种基于DPDK的高效报文传输框架。采用混合中断轮询机制、用户态协议实现，简化了报文传输处理环节，从而减小了报文传输的延迟，提高了通信传输速率，实现了节点间高效通信。实验表明，本框架能充分发挥网络链路的物理带宽，消除了机群系统的通信瓶颈。

[1]Drogemuler K,Kuhl D,Blank J,et al.Current Progress of Advanced High Speed Parallel Optical Links for Computer Clusters and Switch Systems[C]∥IEEE 2000 Electronic Components and Technology Conference,2000:1227-1235.

[2]Rajkumar Buyya.High Performance Cluster Computing: Architectures and Systems [M].USA: Prentice Hall,1999.

[3]Sodan A C,Machina J,Deshmeh A,et al.Parallelism Via Multithreaded and Multicore CPUs[J].Computer,2010,43(3): 24-32.

[4]Brodtkorb A R,Dyken C,Hagen T R,et al.State-of-the-art in Heterogeneous Computing[J].Scientific Programming,2010,18(1):1-33.

[5]Vetter J S.Contemporary High Performance Computing from Petascale Toward Exascale[M].6000 Broken Sound Parkway,NW,USA: CRC Press,2013.

[6]Salim J H,Olsson R,Kuznetsov A,et al.Beyond softnet[C]∥In: Proceedings of the 5th Annual Linux Showcase & Conference,1999:165-172.

[7]柳斌，李之棠，黎耀.基于NAPI的高速网络捕包技术[[J].通信学报，2005(b01):145-148.

[8]Shivam P,Wyckoff P,Panda D.EMP: Zero-copy OS-bypass NIC-driven Gigabit Ethernet Message Passing[C]∥Supercomputing,ACM/IEEE 2001 Conference.IEEE,2001: 49.

[9]LUIGI R.Revisiting Network I/O APIs: The Netmap Framework[J].Communications of the ACM,2012,55(3):45-51.

[10] Casoni M，Grazia C A,Patriciello N.On the Performance of Linux Container with Netmap/VALE for Networks virtualization[C]∥2013 19th IEEE International Conference on Networks (ICON),2013:1-6.

[11] Stevens W R.UNIX网络编程(第1卷：套接字API)[M].2版.施振川，周利民，孙宏晖，等，译.北京：清华大学出版社，1999.

[12] Deri L，NSPA Via,Km B,etal.lmproving Passive Paeket Capture: Beyond Device Polling[C]∥Proceedings of SANE,2004.

[13] Deri L,Francesco F.Exploiting Commodity Multi-core Systems for Network Tracffic Analysis [R/OL].2009.http:∥lucu.ntop.org.

[14] DPDK. DPDK[EB/OL].http://dpdk.org/．

[15] Stevens W R.TCP/IP详解(卷1)——协议[M].北京：机械工业出版社,2011．