基于DPDK混合中斷輪詢模式的報文傳輸框架

趙歡歡，張根全，張惠鑫

(1.中國電子科技集團公司第五十四研究所，河北 石家莊 050081；2.河北廣電信息網(wǎng)絡集團股份有限公司石家莊分公司，河北 石家莊 050000)

0　引言

隨著Hippi和ATM等高速網(wǎng)絡交換技術的應用，具備高效率、低消耗等優(yōu)點的機群系統(tǒng)[1-2]已成為實現(xiàn)并行計算的主流技術。CPUs、GPUs異構(gòu)計算模型[3-5]的提出，更使得機群系統(tǒng)中單節(jié)點計算能力得到了極大提高。但是高速局域網(wǎng)絡技術提供的Gb級帶寬的物理鏈路，卻由于linux等操作系統(tǒng)在協(xié)議棧的實現(xiàn)效率無法滿足鏈路傳輸要求，導致單節(jié)點機最大可以處理的數(shù)據(jù)量只達到百Mb級，節(jié)點間網(wǎng)絡通信開銷成為影響計算性能的制約因素。因此設法提高通信傳輸速率對于提高整個機群系統(tǒng)的并行計算能力具有重要意義。

目前，提高網(wǎng)絡傳輸速率的方法大多基于以下兩方面：① 降低中斷開銷，盡量使用輪詢的方式一次處理多個數(shù)據(jù)包，如NAPI技術[6-7]已在linux當前版本的系統(tǒng)內(nèi)核中使用；② 內(nèi)存零拷貝的方式[8]，減小內(nèi)核到用戶空間的包復制，如netmap框架[9-11]。此外，著名的PF-Ring框架[12-13]結(jié)合兩個方面，具有極高的性能表現(xiàn)。但linux的分時處理機制帶來的系統(tǒng)調(diào)度會對性能帶來負面影響，同時上述方案沒有發(fā)揮CPU多核的優(yōu)勢。

1　報文傳輸技術體制

目前應用廣泛的典型網(wǎng)絡傳輸框架有基于系統(tǒng)內(nèi)核層的Libpcap和基于用戶態(tài)處理的PF-Ring框架，近兩年DPDK技術隨著開源而高速發(fā)展，本節(jié)對其進行分析對比。

1.1　Libpcap

傳統(tǒng)的網(wǎng)絡節(jié)點獲取報文大多采用基于TCP/IP 協(xié)議棧的函數(shù)庫Libpcap[11]，它是一個獨立于系統(tǒng)的用戶層包捕獲的API接口，利用內(nèi)核層網(wǎng)絡協(xié)議棧處理底層通信。但是報文傳輸過程中因操作系統(tǒng)低效的網(wǎng)絡協(xié)議構(gòu)架導致頻繁的上下文切換、系統(tǒng)調(diào)用以及數(shù)據(jù)拷貝等開銷，造成其低下的通信性能無法適應大規(guī)模機群系統(tǒng)的通信需求.。

1.2　PF-Ring

PF-Ring[12-13]是Luca設計的基于Linux內(nèi)核級數(shù)據(jù)包處理框架，核心思想是通過旁路了操作系統(tǒng)，將網(wǎng)卡接收到的數(shù)據(jù)存儲在環(huán)狀緩存區(qū)內(nèi)，由用戶應用直接從環(huán)狀緩存區(qū)讀取數(shù)據(jù)。

PF-Ring支持3種工作模式，工作模式1、2的效率較高。其中，框架工作模式1使用TNAPI技術[13]，利用多線程同步輪詢網(wǎng)卡接收隊列，復制數(shù)據(jù)到內(nèi)核層緩存，使用DMA均衡到各個CPU核，利用多核提升性能。但由于數(shù)據(jù)包捕獲及預處理仍在內(nèi)核層完成，與用戶層數(shù)據(jù)交互會增加反復調(diào)度的性能消耗，同時TNAPI技術為提高數(shù)據(jù)包的捕獲，發(fā)送隊列被禁用。框架工作模式2使用網(wǎng)卡網(wǎng)絡處理單元直接從網(wǎng)卡數(shù)據(jù)映射到DMA環(huán)形緩存，比模式1提高了性能，但是一次只能由一個應用使用DMA環(huán)形緩存，對多連接情況需同步不同的應用。硬件方面，要求更改網(wǎng)卡驅(qū)動，存在支持的第三方網(wǎng)卡驅(qū)動有限且網(wǎng)卡驅(qū)動穩(wěn)定性無法保證等問題。

1.3　DPDK技術

DPDK[14](Intel Data Plane Development Kit)是Intel提供的數(shù)據(jù)平面開發(fā)工具集，其核心組件由一系列用戶層上的數(shù)據(jù)包處理庫函數(shù)和驅(qū)動組成，為高性能數(shù)據(jù)包處理提供基礎操作。內(nèi)核層模塊主要實現(xiàn)輪詢模式的網(wǎng)卡驅(qū)動和接口，并提供PCI設備的初始化工作；用戶層模塊則提供大量給用戶直接調(diào)用的函數(shù)。

DPDK通過環(huán)境抽象層旁路內(nèi)核協(xié)議棧，同時采用多項技術，實現(xiàn)了在x86處理器架構(gòu)下的高性能報文處理能力。這些技術大致歸為：① 輪詢，可避免中斷上下文切換的開銷；② 用戶態(tài)驅(qū)動，既規(guī)避了不必要的內(nèi)存拷貝，又避免了系統(tǒng)調(diào)用；③ 親和與獨占，利用線程的CPU綁定，避免線程不同核間頻繁切換帶來的開銷；④ 降低訪存開銷，采用內(nèi)存大頁降低TLB miss，內(nèi)存多通道交錯訪問提高內(nèi)存訪問帶寬等。

但是，與使用Linux內(nèi)核的應用框架相比，數(shù)據(jù)包將不再通過內(nèi)核，而通過DPDK的專用路徑，從網(wǎng)卡直接拷貝到用戶空間，交由用戶應用處理，所以使用DPDK后，無法再使用系統(tǒng)內(nèi)核協(xié)議棧，而DPDK本身并不具備協(xié)議棧的功能，因此用戶需要自己設計/實現(xiàn)用戶態(tài)網(wǎng)絡協(xié)議棧。

2　基于DPDK的報文傳輸框架設計

2.1　框架設計思路

如圖1所示，本框架是一個linux系統(tǒng)上的多核加速數(shù)據(jù)傳輸解決方案，運行在多個核上，為上層應用提供高性能的網(wǎng)絡數(shù)據(jù)通道。

圖1　傳輸框架架構(gòu)

多核并行計算中，通常采用多進程/線程實現(xiàn)。在傳統(tǒng)多進程/線程的編程中，鎖是保證數(shù)據(jù)安全的重要手段。由于資源的競爭,進程/線程不得不阻塞等待。據(jù)實驗測試，一個高并發(fā)的應用，20% ～70%的時間可能耗在無謂的鎖等待上。

因此，采用基于分片的設計，使每一個核對應一個線程，每個核有獨占的資源：CPU、內(nèi)存、網(wǎng)絡。多核之間沒有數(shù)據(jù)共享、鎖等需要阻塞同步的操作，保證多核間操作的異步性，從而達到高性能和低延遲的目標。由于多核間沒有資源的競爭，隨著核數(shù)量的增加，擴展性和性能也會隨之提升。

鑒于DPDK為底層處理和I/O數(shù)據(jù)包提供硬件處理功能，本框架提供了一套在DPDK之上的數(shù)據(jù)處理、網(wǎng)絡堆棧實現(xiàn)和應用支撐接口等功能的工具包。其中：① 數(shù)據(jù)接收模塊采用基于狀態(tài)的混合終端輪詢模式加速數(shù)據(jù)接收，并提供了數(shù)據(jù)過濾操作；② 網(wǎng)絡協(xié)議模塊中高度模塊化網(wǎng)絡堆棧，并在單線程環(huán)境下優(yōu)化原網(wǎng)絡層服務和功能，以及應用層需要的TCP/UDP協(xié)議[15]處理，解析網(wǎng)絡棧按需要可配置，指定加載全部或部分功能特性；③ 接口適配模塊提供了socket及鏈路層數(shù)據(jù)接口，供上層不同應用選擇。

2.2　基于狀態(tài)的混合中斷輪詢機制

由于機群系統(tǒng)中可能存在潮汐效應，大部分時間處于平穩(wěn)的高流量狀態(tài)，中斷方式會使操作系統(tǒng)陷入中斷頻繁響應環(huán)節(jié)，產(chǎn)生的消息處理開銷影響系統(tǒng)的處理性能；某段時間網(wǎng)絡數(shù)據(jù)流量可能很低或無數(shù)據(jù)傳輸，輪詢方式就會出現(xiàn)高速端口下低負荷運行，加重CPU 的負載。

針對上述情況，一種比較好的實現(xiàn)方法就是采用混合中斷輪詢驅(qū)動進行傳輸控制。該機制結(jié)合了中斷與輪詢，高負載情況下輪詢操作保證了數(shù)據(jù)不丟包，而低負載情況下中斷保證CPU的其他計算工作，從而很好地平衡延遲與吞吐量要求。

根據(jù)混合中斷輪詢驅(qū)動機制得到的有限狀態(tài)機模型如圖2所示。

圖2　狀態(tài)機模型

其中：

① 系統(tǒng)開中斷狀態(tài)下的初始狀態(tài)轉(zhuǎn)變?yōu)殛P中斷的輪詢狀態(tài)，并配置的滑動窗口尺寸W，初始化輪詢滑動接收報文個數(shù)R；

② 若R>W，說明吞吐量接近或達到平衡狀態(tài)，則繼續(xù)輪詢模式；

③ 若R

④ 單位時間中斷量大于閥值時，進入輪詢模式；

⑤ 單位時間中斷量小于閥值時，繼續(xù)中斷模式；

⑥ 內(nèi)存耗盡，過渡到初始狀態(tài)后，進行①。

2.3　報文處理過程

報文傳輸處理中，旁路了操作系統(tǒng)，由框架直接讀取網(wǎng)絡鏈路層數(shù)據(jù)，并由用戶層協(xié)議棧實現(xiàn)報文的解析、組包等處理操作。輪詢狀態(tài)下，框架接收線程不間斷讀取網(wǎng)卡數(shù)據(jù)；中斷狀態(tài)下，框架接收網(wǎng)卡中斷信號后，喚醒接收線程進行數(shù)據(jù)讀取。流程如圖3所示。

其中：

① 基于分片的設計，使得框架會對每個核進行資源分配，每一個線程分配一個核；

② 對預分配給框架的物理內(nèi)存進行分片，每個核占有獨立的內(nèi)存空間，獨立完成對內(nèi)存區(qū)域的分配和釋放管理；

③ 每個核與物理網(wǎng)卡的一個接收隊列和發(fā)送隊列進行綁定(數(shù)據(jù)連接也被分片)，每個核只處理各自負責的連接；

④ 中斷狀態(tài)下， 接收線程始終處于睡眠狀態(tài)，每當網(wǎng)卡產(chǎn)生中斷信號，隨即喚醒接收線程，進行數(shù)據(jù)讀取操作，至用戶層環(huán)形緩存后進行處理；

⑤ 輪詢狀態(tài)下，接收線程始終處于激活狀態(tài)，不間斷直接讀取接收隊列數(shù)據(jù)到用戶層環(huán)形緩存后進行處理；

⑥ 數(shù)據(jù)經(jīng)協(xié)議棧封裝后，通過DPDK直接向網(wǎng)卡發(fā)送。

圖3　報文處理流程

3　試驗驗證

為了對本框架(DPDK+TCP/IP)進行性能分析，與專用數(shù)據(jù)發(fā)送服務器采取光纖連接的方式對所實現(xiàn)的實例進行了性能測試。測試在普通商用服務器(CPU：Xeon E5 4核，2顆，主頻3.50 GHz；內(nèi)存：16 G；操作系統(tǒng)：Red Hat Enterprise Linux Server 6.5)，使用萬兆網(wǎng)卡Intel 82599進行。

接收端接收報文后統(tǒng)計，半小時不丟包則增大流量，直到網(wǎng)卡滿負荷或丟包，測試包長從64～1 500 Byte，測試丟包率為0的情況下的最大包處理速率與網(wǎng)絡帶寬使用情況。

為了極限利用網(wǎng)絡帶寬，在網(wǎng)絡處理的整個流水線上(即數(shù)據(jù)包的整個生命周期中)，不能有任何一級流水處理延時超過報文間的時間間隔，因此數(shù)據(jù)包越小，挑戰(zhàn)越大。試驗結(jié)果如圖4和圖5所示，DPDK由于在高速網(wǎng)絡傳輸中不再產(chǎn)生中斷，在包大小大于256 Byte后，包接收速率基本達到理論值。而PF-RING因為需要一定量的軟中斷處理，消耗了處理時間，包大小大于512 Byte后，包接收速率才接近理論值。

圖4　包速率對比結(jié)果

圖5　通信帶寬使用對比結(jié)果

由圖4和圖5可知，本框架(DPDK+TCP/IP)在包報文處理速率上明顯優(yōu)于PF-RING+TCP/IP和Libpcap，主要是充分利用DPDK技術提高數(shù)據(jù)接收速率，同時在用戶層協(xié)議解析過程中，不需要鎖等同步處理。而PF-RING+TCP/IP雖然采用DNA技術，將網(wǎng)卡數(shù)據(jù)映射到DMA環(huán)形緩存，但對該數(shù)據(jù)處理時需要同步操作，消耗了流水時間；至于Libpcap使用的內(nèi)核級處理，過多的中斷響應降低了效率。

4　結(jié)束語

本文對典型的報文傳輸框架進行了分析，設計并實現(xiàn)了一種基于DPDK的高效報文傳輸框架。采用混合中斷輪詢機制、用戶態(tài)協(xié)議實現(xiàn)，簡化了報文傳輸處理環(huán)節(jié)，從而減小了報文傳輸?shù)难舆t，提高了通信傳輸速率，實現(xiàn)了節(jié)點間高效通信。實驗表明，本框架能充分發(fā)揮網(wǎng)絡鏈路的物理帶寬，消除了機群系統(tǒng)的通信瓶頸。

[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的高速網(wǎng)絡捕包技術[[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網(wǎng)絡編程(第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)——協(xié)議[M].北京：機械工業(yè)出版社,2011．