基于DPDK混合中斷輪詢模式的報(bào)文傳輸框架

趙歡歡，張根全，張惠鑫

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

0　引言

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

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

1　報(bào)文傳輸技術(shù)體制

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

1.1　Libpcap

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

1.2　PF-Ring

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

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

1.3　DPDK技術(shù)

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

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

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

2　基于DPDK的報(bào)文傳輸框架設(shè)計(jì)

2.1　框架設(shè)計(jì)思路

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

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

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

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

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

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

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

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

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

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

其中：

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

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

③ 若R

④ 單位時(shí)間中斷量大于閥值時(shí)，進(jìn)入輪詢模式；

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

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

2.3　報(bào)文處理過程

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

其中：

① 基于分片的設(shè)計(jì)，使得框架會(huì)對(duì)每個(gè)核進(jìn)行資源分配，每一個(gè)線程分配一個(gè)核；

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

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

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

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

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

圖3　報(bào)文處理流程

3　試驗(yàn)驗(yàn)證

為了對(duì)本框架(DPDK+TCP/IP)進(jìn)行性能分析，與專用數(shù)據(jù)發(fā)送服務(wù)器采取光纖連接的方式對(duì)所實(shí)現(xiàn)的實(shí)例進(jìn)行了性能測試。測試在普通商用服務(wù)器(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進(jìn)行。

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

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

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

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

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

4　結(jié)束語

本文對(duì)典型的報(bào)文傳輸框架進(jìn)行了分析，設(shè)計(jì)并實(shí)現(xiàn)了一種基于DPDK的高效報(bào)文傳輸框架。采用混合中斷輪詢機(jī)制、用戶態(tài)協(xié)議實(shí)現(xiàn)，簡化了報(bào)文傳輸處理環(huán)節(jié)，從而減小了報(bào)文傳輸?shù)难舆t，提高了通信傳輸速率，實(shí)現(xiàn)了節(jié)點(diǎn)間高效通信。實(shí)驗(yàn)表明，本框架能充分發(fā)揮網(wǎng)絡(luò)鏈路的物理帶寬，消除了機(jī)群系統(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)絡(luò)捕包技術(shù)[[J].通信學(xué)報(bào)，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)絡(luò)編程(第1卷：套接字API)[M].2版.施振川，周利民，孫宏暉，等，譯.北京：清華大學(xué)出版社，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].北京：機(jī)械工業(yè)出版社,2011．