一種基于DPDK的地面相控陣?yán)走_(dá)數(shù)據(jù)流高性能傳輸機(jī)制

常清宜,龔博雅,魯克文,2,陶 丹

1(北京交通大學(xué) 電子信息工程學(xué)院,北京 100044)

2(中國電子科技集團(tuán)第十五研究所,北京 100026)

1 引 言

地面相控陣?yán)走_(dá)作為現(xiàn)代雷達(dá)的一個(gè)重要分支,充分利用了相控陣天線的特點(diǎn),具有很多傳統(tǒng)機(jī)械雷達(dá)所不具備的優(yōu)勢[1].在氣象預(yù)報(bào)、資源探測、環(huán)境監(jiān)測、空中管制等諸多方面體現(xiàn)了很好的應(yīng)用潛力.地面相控陣?yán)走_(dá)數(shù)據(jù)流具有傳輸速度快、單幀數(shù)據(jù)量大的特點(diǎn),其單通道的傳輸速率一般不低于5Gb/s,單幀雷達(dá)數(shù)據(jù)幀的大小為64KB,而當(dāng)前的硬件設(shè)備對于巨型幀的傳輸支持有限,難以支持完整雷達(dá)數(shù)據(jù)的傳輸.因此,地面相控陣?yán)走_(dá)數(shù)據(jù)流在傳輸和使用的過程中尚需要進(jìn)行復(fù)雜的分割和重組過程.這也給地面相控陣?yán)走_(dá)數(shù)據(jù)流傳輸帶來了極大的挑戰(zhàn).

傳統(tǒng)的雷達(dá)數(shù)據(jù)流傳輸多采用定制化的硬件設(shè)備實(shí)現(xiàn),其優(yōu)點(diǎn)是性能比較好,但缺點(diǎn)是其功能相對固定、可擴(kuò)展性差,且成本較高.因此,如何基于軟件方法以較低的成本實(shí)現(xiàn)地面相控陣?yán)走_(dá)數(shù)據(jù)流的高性能傳輸是十分有必要的.

基于軟件的數(shù)據(jù)傳輸方法十分豐富,其中Linux網(wǎng)絡(luò)協(xié)議棧最為經(jīng)典.許多基于軟件的現(xiàn)代數(shù)據(jù)傳輸技術(shù)如SOCKET編程和多種網(wǎng)絡(luò)傳輸庫(Asio,Muduo等)都采用了Linux網(wǎng)絡(luò)協(xié)議棧作為其底層實(shí)現(xiàn)[2].目前,基于Linux網(wǎng)絡(luò)協(xié)議棧的網(wǎng)絡(luò)傳輸技術(shù)已經(jīng)被廣泛的使用.Kayum S N等人[3]使用基于Asio的高性能計(jì)算軟件框架GeoDRIVE來傳輸大規(guī)模的地震數(shù)據(jù)流.實(shí)驗(yàn)結(jié)果顯示,GeoDRIVE可以支持在32000個(gè)核心上同時(shí)進(jìn)行2500個(gè)地震實(shí)驗(yàn),并且能夠處理跨多個(gè)節(jié)點(diǎn)發(fā)生的故障,具有較強(qiáng)的彈性和可擴(kuò)展性.Klein D等人[4]將Asio與Libfabric和ZeroMQ進(jìn)行比較,結(jié)果顯示在消息的大小逐漸增加的過程中,Asio的數(shù)據(jù)吞吐量是三者中最高的,對CPU資源的消耗處于三者中的中間位置.

Linux網(wǎng)絡(luò)協(xié)議棧具有較強(qiáng)的通用性,使其對于大多數(shù)常見的數(shù)據(jù)傳輸任務(wù)都可以勝任.但是,Linux網(wǎng)絡(luò)協(xié)議棧因?yàn)殒i、上下文切換、中斷、用戶態(tài)與內(nèi)核態(tài)切換、內(nèi)存拷貝等因素,耗費(fèi)了大量CPU時(shí)鐘周期,使得硬件性能得不到充分的利用,難以完成傳輸速率較高、傳輸流量較大的數(shù)據(jù)傳輸任務(wù)[5].

由此,Intel公司開發(fā)了DPDK[6].DPDK技術(shù)的核心優(yōu)化思想在于繞開Linux內(nèi)核繁瑣的處理流程.相對于傳統(tǒng)的Linux內(nèi)核數(shù)據(jù)處理方式,DPDK借助VFIO(Virtual Function I/O,虛擬功能I/O)等技術(shù),屏蔽了硬件中斷,減少了內(nèi)核態(tài)中的諸多操作帶來的性能影響[7].同時(shí),DPDK采用了大頁機(jī)制,減少了處理數(shù)據(jù)報(bào)文時(shí)因緩存丟失帶來的開銷[8].DPDK也提供了RSS和Flow Director等網(wǎng)卡多隊(duì)列技術(shù)的具體實(shí)現(xiàn),通過使用這些技術(shù)可以充分利用網(wǎng)卡的多隊(duì)列優(yōu)勢,實(shí)現(xiàn)多核并行的數(shù)據(jù)處理[9].

所以,DPDK在需要高性能、低延遲等具有較高要求的場合具有極大的應(yīng)用前景.Furukawa M等人[10]將DPDK技術(shù)應(yīng)用于基于遠(yuǎn)程GPU節(jié)點(diǎn)的分布式深度神經(jīng)網(wǎng)絡(luò)計(jì)算,使用DPDK來傳輸神經(jīng)網(wǎng)絡(luò)的梯度數(shù)據(jù),相比于采用標(biāo)準(zhǔn)TCP傳輸方案,采用DPDK方案帶來了2.2～2.5倍的加速效果.Lai L等人[11]基于DPDK框架設(shè)計(jì)了一種新的中間件UDPDK,UDPDK簡化了DPDK的開發(fā)過程,提供了標(biāo)準(zhǔn)的通信接口,用于加速基于UDP的數(shù)據(jù)傳輸過程.實(shí)驗(yàn)結(jié)果顯示,采用UDPDK方案時(shí),端到端延遲減少了69%.

考慮到地面相控陣?yán)走_(dá)數(shù)據(jù)流傳輸時(shí)的高性能要求,本文基于Intel DPDK技術(shù)提出了一種面向地面相控陣?yán)走_(dá)數(shù)據(jù)流的傳輸機(jī)制.該機(jī)制首先針對服務(wù)器CPU單核頻率低的問題提出了基于多核心CPU多線程方法,該方法將具體任務(wù)進(jìn)行分解后交由多個(gè)線程處理,然后通過Ring和Mempool結(jié)構(gòu)進(jìn)行線程間的數(shù)據(jù)交換.其次,針對雷達(dá)數(shù)據(jù)重組和消費(fèi)問題提出了高速組幀和數(shù)據(jù)消費(fèi)方法,該方法通過幀池和幀索引池實(shí)現(xiàn)了雷達(dá)數(shù)據(jù)重組并基于DPDK進(jìn)程間通信機(jī)制設(shè)計(jì)了進(jìn)程間通信協(xié)議,完成了數(shù)據(jù)消費(fèi)過程.最后,為了保證數(shù)據(jù)網(wǎng)絡(luò)傳輸?shù)目煽啃?提出了網(wǎng)絡(luò)報(bào)文緩沖方法,該方法結(jié)合了Mbuf和Mempool數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)了對網(wǎng)絡(luò)報(bào)文的高效管理.

2 總體方案

本文提出的面向地面相控陣?yán)走_(dá)數(shù)據(jù)流的傳輸機(jī)制要求能夠在高速的網(wǎng)絡(luò)環(huán)境中實(shí)現(xiàn)對地面相控陣?yán)走_(dá)數(shù)據(jù)流的轉(zhuǎn)發(fā)、接收和本地消費(fèi).針對如上需求,本文設(shè)計(jì)了3個(gè)模塊分別實(shí)現(xiàn)了以上功能,并根據(jù)服務(wù)器的職能將服務(wù)器分為接入服務(wù)器和計(jì)算服務(wù)器,其中接入服務(wù)器負(fù)責(zé)雷達(dá)數(shù)據(jù)流的轉(zhuǎn)發(fā),計(jì)算服務(wù)器搭載GPU用于運(yùn)行雷達(dá)應(yīng)用程序?qū)走_(dá)數(shù)據(jù)進(jìn)行處理.總體數(shù)據(jù)處理流程如圖1所示,其中各模塊的詳細(xì)介紹如下:

圖1 整體處理流程圖Fig.1 Overall processing flowchart

1)數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊

由于數(shù)據(jù)源發(fā)送數(shù)據(jù)時(shí)其目的IP地址、端口號、MAC地址等定位信息是固定的,為了使計(jì)算服務(wù)器能夠消費(fèi)指定通道的數(shù)據(jù),必須通過軟件的方法改變數(shù)據(jù)包定位信息,使其順利到達(dá)指定計(jì)算服務(wù)器.本模塊通過多張獨(dú)立的網(wǎng)卡接收不同通道的數(shù)據(jù).成功從網(wǎng)卡上獲取到數(shù)據(jù)后,數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊將數(shù)據(jù)進(jìn)行UDP協(xié)議的填充,并將填充完畢之后的數(shù)據(jù)進(jìn)行發(fā)送.發(fā)送時(shí)采用大帶寬網(wǎng)卡以減少對服務(wù)器硬件PCIe接口的占用,發(fā)送時(shí)將不同通道的數(shù)據(jù)并行發(fā)往該網(wǎng)卡的不同隊(duì)列中,充分利用了大帶寬網(wǎng)卡的性能.

2)數(shù)據(jù)網(wǎng)絡(luò)接收模塊

對于多路雷達(dá)數(shù)據(jù)流,轉(zhuǎn)發(fā)時(shí)采用的是同一張網(wǎng)卡,在網(wǎng)絡(luò)傳輸過程中會產(chǎn)生多路數(shù)據(jù)混雜的現(xiàn)象,所以在下一步處理之前必須對多路雷達(dá)數(shù)據(jù)流進(jìn)行區(qū)分.本模塊采用Flow Director技術(shù)實(shí)現(xiàn)了對于多路數(shù)據(jù)的分離.該模塊首先向網(wǎng)卡硬件寫入流匹配規(guī)則用于區(qū)分到達(dá)同一張網(wǎng)卡的多路雷達(dá)數(shù)據(jù),隨后從網(wǎng)卡的不同隊(duì)列上接收數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊發(fā)送的雷達(dá)數(shù)據(jù),成功接收到數(shù)據(jù)后進(jìn)行組幀處理.

3)數(shù)據(jù)本地消費(fèi)模塊

雷達(dá)數(shù)據(jù)重組完畢后需要將重組后的數(shù)據(jù)傳遞給雷達(dá)應(yīng)用程序進(jìn)行處理,所以需要一個(gè)中間件實(shí)現(xiàn)雷達(dá)數(shù)據(jù)的傳遞過程.本模塊通過數(shù)據(jù)獲取接口不斷的從數(shù)據(jù)網(wǎng)絡(luò)接收模塊獲取完整的雷達(dá)數(shù)據(jù)幀,若此時(shí)沒有需要數(shù)據(jù)的應(yīng)用程序,則將數(shù)據(jù)幀丟棄.若有,則通過進(jìn)程間通信接口按照既定的通信協(xié)議將數(shù)據(jù)推送給應(yīng)用程序,應(yīng)用程序收到數(shù)據(jù)后進(jìn)行相應(yīng)的雷達(dá)信號處理.

3 基于多核CPU的多線程方法

由于性能要求較高,若在同一個(gè)CPU核心上完成每個(gè)模塊對應(yīng)的任務(wù),雖然能夠減少多核處理器的核心之間共享臨界資源和線程間通信所帶來的性能損耗,但是較低的單核頻率無法滿足性能要求,若采用較高單核頻率的CPU又會極大增加成本.

為了充分利用CPU多核優(yōu)勢,提高系統(tǒng)的整體性能,本文設(shè)計(jì)了一種適用于多核CPU的多線程方法,該方法通過將任務(wù)分解為不同子任務(wù),并借助CPU親和性技術(shù)將任務(wù)執(zhí)行線程與具體的CPU核心進(jìn)行綁定,使得任務(wù)線程和CPU核心呈現(xiàn)1:1的關(guān)系,以減少系統(tǒng)自動調(diào)度CPU核心帶來的上下文切換損失.對于每一個(gè)線程使用的內(nèi)存空間也按照其對應(yīng)的CPU核心所在的NUMA節(jié)點(diǎn)進(jìn)行分配,減少了CPU中斷、資源競爭和跨NUMA節(jié)點(diǎn)訪問內(nèi)存對性能帶來的影響.具體而言,本文將數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊以及數(shù)據(jù)網(wǎng)絡(luò)接收模塊的任務(wù)進(jìn)行了如下的分解:

1)數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊

本文將數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊的轉(zhuǎn)發(fā)任務(wù)分解成為數(shù)據(jù)獲取、協(xié)議填充和數(shù)據(jù)發(fā)送3個(gè)子任務(wù),其中數(shù)據(jù)獲取子任務(wù)對CPU資源消耗較高,若CPU資源不足容易出現(xiàn)丟包的情況,所以數(shù)據(jù)獲取子任務(wù)交由一個(gè)單獨(dú)的線程完成.由于協(xié)議填充子任務(wù)對CPU資源消耗較低,所以將協(xié)議填充子任務(wù)和數(shù)據(jù)發(fā)送子任務(wù)交由一個(gè)線程執(zhí)行.

2)數(shù)據(jù)網(wǎng)絡(luò)接收模塊

將數(shù)據(jù)網(wǎng)絡(luò)接收模塊的數(shù)據(jù)接收任務(wù)分解成為數(shù)據(jù)獲取和數(shù)據(jù)組幀兩個(gè)子任務(wù),和轉(zhuǎn)發(fā)任務(wù)中的設(shè)計(jì)一致,數(shù)據(jù)獲取子任務(wù)交由一個(gè)單獨(dú)的線程完成.而數(shù)據(jù)組幀子任務(wù)同樣對CPU資源具有較高的要求,所以數(shù)據(jù)組幀子任務(wù)同樣交由一個(gè)單獨(dú)的線程完成.

通過上述方法,服務(wù)器CPU的多核優(yōu)勢得到了充分利用.還需要解決在數(shù)據(jù)傳輸速率較高前提下的多線程間通信問題.傳統(tǒng)的線程間的通信方法多數(shù)采用共享內(nèi)存實(shí)現(xiàn),多個(gè)線程共享同一片內(nèi)存區(qū)域,同時(shí)使用線程安全的數(shù)據(jù)結(jié)構(gòu)同步對應(yīng)內(nèi)存區(qū)域的索引量,而不是傳輸整段的數(shù)據(jù).但是傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)如C++標(biāo)準(zhǔn)庫中的隊(duì)列等進(jìn)行數(shù)據(jù)同步時(shí)都采用鎖機(jī)制實(shí)現(xiàn),在高速程序中,采用鎖機(jī)制會大大降低程序的性能,在極端情況下甚至?xí)枞€程導(dǎo)致程序崩潰.

DPDK中的Ring是一種無鎖隊(duì)列,能夠進(jìn)行高速數(shù)據(jù)的傳遞.Ring采用頭尾指針來標(biāo)記生產(chǎn)者和消費(fèi)者生產(chǎn)或者是消費(fèi)的位置,其內(nèi)部操作采用CAS指令具體實(shí)現(xiàn),可避免鎖的競爭機(jī)制.同時(shí)Ring支持批量入隊(duì)/出隊(duì)操作,只需要一次系統(tǒng)調(diào)用的開銷就可以處理多個(gè)數(shù)據(jù),進(jìn)一步提升了數(shù)據(jù)傳輸性能[12].

DPDK中的內(nèi)存池Mempool能夠高效的管理數(shù)據(jù),Mempool在程序初始化階段在大頁內(nèi)存中分配共享內(nèi)存用于保存固定大小的對象,有效避免了因?yàn)樵诔绦蜻\(yùn)行時(shí)動態(tài)分配內(nèi)存帶來的性能損失.同時(shí)Mempool內(nèi)部維護(hù)了一個(gè)共享的Ring結(jié)構(gòu)用于存儲可用對象單元的具體地址,為了減少多個(gè)CPU核心資源競爭所帶來的性能損失,Mempool為每一個(gè)CPU核心分配了一定大小的緩存,當(dāng)CPU核心向Mempool申請對象時(shí),首先會從對應(yīng)的緩存中獲取,當(dāng)緩存中沒有可用對象時(shí),才會向共享的Ring中獲取對象,減少了多個(gè)CPU核心資源競爭所帶來的性能損失[13].

基于隊(duì)列Ring和內(nèi)存池Mempool結(jié)構(gòu),本文改進(jìn)了傳統(tǒng)的線程間通信方法,改進(jìn)后的線程間通信方法在進(jìn)行通信之前需要在大頁內(nèi)存中建立相應(yīng)的Ring和Mempool,創(chuàng)建完畢后可以使用相應(yīng)的Ring和Mempool進(jìn)行通信.當(dāng)線程1要向線程2傳遞數(shù)據(jù)時(shí),線程1會向Mempool申請內(nèi)存空間,申請成功后線程1將要進(jìn)行傳遞的數(shù)據(jù)拷貝到申請的內(nèi)存空間中,同時(shí)將存有該內(nèi)存空間地址的指針?biāo)腿隦ing中.接著線程2從Ring中取出指針,通過指針訪問Mempool中指定內(nèi)存空間中的數(shù)據(jù),將數(shù)據(jù)進(jìn)行一次拷貝,然后對數(shù)據(jù)進(jìn)行下一步的處理.當(dāng)數(shù)據(jù)處理完畢后,線程2進(jìn)行內(nèi)存空間的釋放,即將對應(yīng)的內(nèi)存空間歸還給Mempool,解除對Mempool中對應(yīng)內(nèi)存空間的占用.

4 高速組幀和數(shù)據(jù)消費(fèi)方法

由于完整的地面相控陣?yán)走_(dá)數(shù)據(jù)幀的大小高達(dá)64KB,故在實(shí)際操作的過程中需要對完整的雷達(dá)數(shù)據(jù)幀做分包處理,即將完整的數(shù)據(jù)幀分解為若干小數(shù)據(jù)包.因此,在應(yīng)用程序使用之前必須完成組幀的操作,將小數(shù)據(jù)包恢復(fù)為完整的雷達(dá)數(shù)據(jù)幀.傳統(tǒng)的組幀方法是將數(shù)據(jù)幀直接保存在數(shù)組中并通過加鎖的方式來保證多線程訪問時(shí)的安全性.在低速情況下這種方案可以較好的實(shí)現(xiàn)組幀功能,但是由于加鎖操作會消耗大量的CPU時(shí)間片,這會影響組幀的性能.相控陣?yán)走_(dá)數(shù)據(jù)幀采用幀序號的方式來區(qū)別不同的幀,為了防止數(shù)據(jù)類型的溢出,幀序號一般采用循環(huán)的方式對每一幀進(jìn)行編號,當(dāng)幀序號取值范圍比較大時(shí),需要消耗較大的內(nèi)存空間才能保存所有數(shù)據(jù)幀.

為此,本文設(shè)計(jì)了一種基于幀池和幀索引池的高速數(shù)據(jù)組幀方法.其中幀池用于保存重組后的數(shù)據(jù)幀,采用Mempool實(shí)現(xiàn),由于Mempool數(shù)據(jù)結(jié)構(gòu)具有內(nèi)存池的特性,只要Mempool中有空閑的空間就可以保證程序的正常運(yùn)行,根據(jù)后續(xù)數(shù)據(jù)處理的快慢可以合理設(shè)置Mempool的大小以達(dá)到減少內(nèi)存消耗的目的.幀索引池就是一個(gè)指針數(shù)組,用于高效管理幀池中的具體數(shù)據(jù),通過這種方式避免了對數(shù)據(jù)的直接操作,采用指針的方式管理數(shù)據(jù),避免了對數(shù)據(jù)直接加鎖的操作,提升了數(shù)據(jù)處理效率.數(shù)據(jù)包組幀的流程主要分為以下6個(gè)步驟:

步驟1.接收線程從網(wǎng)卡上接收并校驗(yàn)數(shù)據(jù)后將數(shù)據(jù)存放在棧上的臨時(shí)內(nèi)存中.

步驟2.將數(shù)據(jù)拷貝到相應(yīng)的用于線程間通信的Mempool中,并將數(shù)據(jù)所在的地址追加到用來進(jìn)行線程中通信的隊(duì)列Ring隊(duì)尾.

步驟3.重復(fù)上述步驟,繼續(xù)處理從網(wǎng)卡中接收到的剩余的數(shù)據(jù)包.

步驟4.組幀線程從Ring中取出待處理數(shù)據(jù)包的地址.

步驟5.解析數(shù)據(jù)包,得到其具體的幀序號和包序號.

步驟6.根據(jù)解析出來的幀序號和包序號,將數(shù)據(jù)包拷貝到幀池對應(yīng)位置上并建立相應(yīng)索引.

組幀完成后雷達(dá)應(yīng)用程序需要消費(fèi)完整的雷達(dá)數(shù)據(jù)幀,但由于數(shù)據(jù)網(wǎng)絡(luò)接收程序、數(shù)據(jù)本地消費(fèi)程序和雷達(dá)應(yīng)用程序分別是同一臺機(jī)器上運(yùn)行的不同的進(jìn)程,如果要進(jìn)行數(shù)據(jù)的傳遞,需要解決兩個(gè)問題:1)如何在進(jìn)程間進(jìn)行高效的通信;2)如何在這3個(gè)進(jìn)程之間建立連接.

本文借助了DPDK中進(jìn)程通信的模型實(shí)現(xiàn)了上述3個(gè)進(jìn)程之間的通信.DPDK進(jìn)程通信的模型將進(jìn)程分為主進(jìn)程和從進(jìn)程,在主進(jìn)程中,DPDK將其正在使用的內(nèi)存配置的詳細(xì)信息記錄到內(nèi)存映射文件中,包括進(jìn)程正在使用的大頁內(nèi)存、它們映射到的虛擬地址、存在的內(nèi)存通道數(shù)量等.當(dāng)從進(jìn)程啟動時(shí),這些文件被讀取,并且EAL在從進(jìn)程中重新創(chuàng)建相同的內(nèi)存配置,以便在進(jìn)程之間共享所有內(nèi)存區(qū)域,多進(jìn)程之間可以通過該共享內(nèi)存進(jìn)行通信[14].

本文設(shè)計(jì)了一套進(jìn)程間通信協(xié)議用于處理各進(jìn)程之間的連接的建立和斷開.當(dāng)應(yīng)用程序需要數(shù)據(jù)時(shí),會向數(shù)據(jù)本地消費(fèi)子模塊發(fā)送建立連接的請求,數(shù)據(jù)本地消費(fèi)子模塊接收到請求之后將對請求內(nèi)容進(jìn)行解析,請求的內(nèi)容包括建立連接和斷開連接的標(biāo)志位和對應(yīng)的請求或是斷開的數(shù)據(jù)通道編號.

若是斷開連接的請求,則停止對應(yīng)通道數(shù)據(jù)的發(fā)送.若是建立連接的請求,則向應(yīng)用程序發(fā)出回應(yīng),表示請求已經(jīng)收到并處理完成,應(yīng)用程序收到響應(yīng)后,進(jìn)行數(shù)據(jù)接收的相關(guān)準(zhǔn)備工作,準(zhǔn)備工作完畢后應(yīng)用程序再向數(shù)據(jù)本地消費(fèi)子模塊回應(yīng),表示數(shù)據(jù)接收的準(zhǔn)備工作已經(jīng)完成,可以發(fā)送數(shù)據(jù).而數(shù)據(jù)本地消費(fèi)子模塊收到應(yīng)用程序的回應(yīng)后將從數(shù)據(jù)網(wǎng)絡(luò)接收模塊獲取對應(yīng)通道的數(shù)據(jù)并發(fā)送給應(yīng)用程序.

5 網(wǎng)絡(luò)報(bào)文緩沖方法

由于本文中涉及的多個(gè)模塊之間需要通過網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳遞,例如數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)子模塊與數(shù)據(jù)網(wǎng)絡(luò)接收子模塊之間的數(shù)據(jù)傳遞就是通過網(wǎng)絡(luò)進(jìn)行的.而網(wǎng)絡(luò)報(bào)文的緩沖區(qū)是保證網(wǎng)絡(luò)報(bào)文高效傳遞的關(guān)鍵,在網(wǎng)絡(luò)堵塞時(shí)可以保存一定量的數(shù)據(jù),防止數(shù)據(jù)丟失.所以,實(shí)現(xiàn)一個(gè)高效且統(tǒng)一的網(wǎng)絡(luò)報(bào)文緩沖區(qū)是十分有必要的.

總的來說,針對網(wǎng)絡(luò)幀的元數(shù)據(jù)和數(shù)據(jù)本身存放一致與否,對網(wǎng)絡(luò)幀的封裝主要有兩種方式,這兩種網(wǎng)絡(luò)幀封裝方式的優(yōu)缺點(diǎn)如表1所示.

表1 網(wǎng)絡(luò)幀封裝方式Table 1 Network frame encapsulation

出于性能考慮,本文中的網(wǎng)絡(luò)報(bào)文緩沖區(qū)采用第1種方案實(shí)現(xiàn),將網(wǎng)絡(luò)報(bào)文保存在名為Mbuf的結(jié)構(gòu)體中.Mbuf主要由4部分組成:

1)Mbuf結(jié)構(gòu)區(qū)域,其中保存了Mbuf的一些基本信息,如Mbuf的大小、Mbuf的地址等.

2)頭部區(qū)域,其中保存了一些控制信息,如幀內(nèi)容、事件等.

3)數(shù)據(jù)區(qū)域,其中保存的就是完整的報(bào)文.

4)尾部區(qū)域,該區(qū)域是預(yù)留的空間,方便數(shù)據(jù)的擴(kuò)展.

通過Mbuf結(jié)構(gòu),兩個(gè)模塊間可以對網(wǎng)絡(luò)報(bào)文進(jìn)行統(tǒng)一的管理,有利于業(yè)務(wù)的實(shí)現(xiàn).為了方便管理Mbuf同時(shí)進(jìn)一步提高性能,本文引入了Mempool數(shù)據(jù)結(jié)構(gòu),將Mempool與Mbuf結(jié)合使用,通過內(nèi)存池Mempool來管理Mbuf.即在程序中通過Mempool創(chuàng)建一個(gè)Mbuf對象池作為網(wǎng)絡(luò)報(bào)文的緩沖區(qū),需要Mbuf對象時(shí)直接從對象池中獲取,使用完畢后將Mbuf對象歸還給對象池.通過這種方式一方面對內(nèi)存空間進(jìn)行了循環(huán)利用,減少了對內(nèi)存空間的使用;另一方面避免了在程序運(yùn)行過程中動態(tài)分配Mbuf對象所帶來的開銷,加快了數(shù)據(jù)包通過網(wǎng)絡(luò)傳輸?shù)男?

網(wǎng)絡(luò)報(bào)文的緩沖流程如圖2所示,主要分為以下5個(gè)步驟:

圖2 網(wǎng)絡(luò)報(bào)文緩沖流程圖Fig.2 Network packet buffering flowchart

步驟1.在原始報(bào)文準(zhǔn)備好的前提下向Mempool緩沖區(qū)申請一個(gè)Mbuf對象.

步驟2.若此時(shí)Mempool緩沖區(qū)中存在空閑Mbuf對象則申請成功,否則拋出異常.

步驟3.成功申請到Mbuf對象后,將報(bào)文原始信息和元數(shù)據(jù),如:IP地址、端口號等信息寫入Mbuf對應(yīng)的區(qū)域.

步驟4.將封裝好的Mbuf送入網(wǎng)卡等待發(fā)送.

步驟5.網(wǎng)卡成功發(fā)送Mbuf中全部報(bào)文信息后將Mbuf空間歸還給Mempool緩沖區(qū).

6 實(shí)驗(yàn)分析

6.1 測試環(huán)境說明

實(shí)驗(yàn)環(huán)境總體由3臺服務(wù)器、1臺上位機(jī)和FPGA數(shù)據(jù)源組成,其中1臺服務(wù)器為接入服務(wù)器,1臺為監(jiān)控服務(wù)器,另外1臺服務(wù)器為計(jì)算服務(wù)器,上位機(jī)負(fù)責(zé)控制FPGA數(shù)據(jù)源發(fā)送雷達(dá)數(shù)據(jù),接入服務(wù)器負(fù)責(zé)接入FPGA數(shù)據(jù)源發(fā)送的雷達(dá)數(shù)據(jù)并轉(zhuǎn)發(fā)給計(jì)算服務(wù)器,計(jì)算服務(wù)器用于接收接入服務(wù)器轉(zhuǎn)發(fā)的雷達(dá)數(shù)據(jù)并進(jìn)行相應(yīng)的雷達(dá)信號處理.監(jiān)控服務(wù)器用于收集相關(guān)的性能指標(biāo)并進(jìn)行可視化展示,服務(wù)器具體配置如表2所示.

表2 服務(wù)器配置Table 2 Server configuration

在測試開始之前需要對相應(yīng)配置進(jìn)行調(diào)整以獲得最佳性能,主要從以下兩個(gè)方面進(jìn)行調(diào)整:

1)硬件設(shè)置

關(guān)閉CPU的省電模式和超線程功能,采用CPU的性能模式,手動調(diào)整CPU頻率為最高頻率.

2)DPDK配置

采用1GB而不是2MB的大頁內(nèi)存以減少頁面緩存丟失的概率,同時(shí)將CPU線程從系統(tǒng)線程調(diào)度器中卸載,并通過isolcpus參數(shù)隔離DPDK使用的CPU,減少CPU資源的競爭,以提高系統(tǒng)整體性能.

6.2 數(shù)據(jù)網(wǎng)絡(luò)傳輸性能測試

本節(jié)測試首先將本文中提出的傳輸機(jī)制與傳統(tǒng)的基于Linux網(wǎng)絡(luò)協(xié)議棧的網(wǎng)絡(luò)傳輸庫Asio進(jìn)行了網(wǎng)絡(luò)總流量的對比.本次測試中的網(wǎng)絡(luò)總流量定義為測試時(shí)間內(nèi)流經(jīng)接入服務(wù)器上發(fā)送網(wǎng)卡的平均流量,計(jì)算方式為測試過程中流經(jīng)接入服務(wù)器上發(fā)送網(wǎng)卡的數(shù)據(jù)總量除以測試時(shí)間,該指標(biāo)的數(shù)值越高,說明對應(yīng)方法的數(shù)據(jù)網(wǎng)絡(luò)發(fā)送性能越強(qiáng).本次對比測試中每個(gè)通道的傳輸速率被限制為5Gb/s,測試的數(shù)據(jù)包長為1472字節(jié),測試中不斷增加數(shù)據(jù)通道數(shù),并統(tǒng)計(jì)不同數(shù)據(jù)通道數(shù)下的不同方法的網(wǎng)絡(luò)總流量.實(shí)驗(yàn)結(jié)果如圖3所示.

圖3 數(shù)據(jù)網(wǎng)絡(luò)傳輸性能對比圖Fig.3 Data network transmission performance comparison chart

由圖3可知,當(dāng)數(shù)據(jù)通道數(shù)小于等于3時(shí)本文方案和Asio都能夠完成數(shù)據(jù)傳輸任務(wù),網(wǎng)絡(luò)總流量都呈現(xiàn)線性增長的趨勢.由于本文方案采用DPDK技術(shù)作為數(shù)據(jù)傳輸?shù)幕A(chǔ),相比于Linux網(wǎng)絡(luò)協(xié)議棧的性能有較大提升.而本文提出的網(wǎng)絡(luò)報(bào)文緩沖方法結(jié)合了幀數(shù)據(jù)和元數(shù)據(jù)共同存放的思想和對象池的思想,能夠高效的進(jìn)行網(wǎng)絡(luò)報(bào)文的緩沖,能夠有效的處理由于網(wǎng)絡(luò)擁塞帶來的丟包現(xiàn)象.所以,當(dāng)數(shù)據(jù)通道數(shù)為4以上時(shí),采用本文方案時(shí)網(wǎng)絡(luò)總流量依然呈現(xiàn)線性增長趨勢,而采用Asio方法時(shí),網(wǎng)絡(luò)總流量增長十分緩慢,丟包現(xiàn)象十分嚴(yán)重.數(shù)據(jù)通道數(shù)為4時(shí),Asio已經(jīng)無法滿足性能要求,網(wǎng)絡(luò)總流量僅為2,400MB/s左右.通道數(shù)增加到5時(shí),網(wǎng)絡(luò)總流量相比于4通道時(shí)增長率僅為13%.當(dāng)數(shù)據(jù)通道數(shù)增長到6以上時(shí),網(wǎng)絡(luò)總流量不再增長,此時(shí)的網(wǎng)絡(luò)總流量在2,800MB/s左右,已經(jīng)達(dá)到了Asio的性能瓶頸.

為了進(jìn)一步對比本文中提出的傳輸機(jī)制與傳統(tǒng)方法的數(shù)據(jù)網(wǎng)絡(luò)接收性能,本節(jié)繼續(xù)對本文中的傳輸機(jī)制和現(xiàn)有方法在數(shù)據(jù)包捕獲率方面進(jìn)行了對比測試,本次測試中數(shù)據(jù)包的捕獲率定義為計(jì)算服務(wù)器上實(shí)際接收到的數(shù)據(jù)包占數(shù)據(jù)源發(fā)送的數(shù)據(jù)包的比例,該值越大說明對應(yīng)方法的數(shù)據(jù)網(wǎng)絡(luò)接收性能越強(qiáng).本次測試中對比的方法仍然是基于Linux網(wǎng)絡(luò)協(xié)議棧的網(wǎng)絡(luò)傳輸庫Asio,測試采用FPGA數(shù)據(jù)源進(jìn)行,測試的數(shù)據(jù)包長為1472字節(jié),測試中不斷增加FPGA數(shù)據(jù)源的輸出流量,并計(jì)算不同流量下兩種方法的數(shù)據(jù)包捕獲率.

實(shí)驗(yàn)結(jié)果如圖4所示,當(dāng)數(shù)據(jù)源發(fā)送流量在15Gb/s以下時(shí),本文方案和Asio網(wǎng)絡(luò)庫都能夠完全捕獲數(shù)據(jù)源發(fā)送的數(shù)據(jù)包.當(dāng)數(shù)據(jù)源發(fā)送流量大于15Gb/s時(shí),Asio網(wǎng)絡(luò)庫的數(shù)據(jù)包捕獲率出現(xiàn)了下降,數(shù)據(jù)源發(fā)送流量為20Gb/s時(shí),Asio網(wǎng)絡(luò)庫的數(shù)據(jù)包捕獲率下降到了90%左右,而隨著數(shù)據(jù)源發(fā)送流量的不斷提高,Asio網(wǎng)絡(luò)庫的數(shù)據(jù)包捕獲率急劇下降,當(dāng)數(shù)據(jù)源發(fā)送流量為為40Gb/s時(shí),Asio網(wǎng)絡(luò)庫的數(shù)據(jù)包捕獲率僅為50%左右,而本文方案在數(shù)據(jù)源發(fā)送流量不斷增加時(shí),數(shù)據(jù)包捕獲率接近100%.本文方案之所以能夠在數(shù)據(jù)網(wǎng)絡(luò)接收測試中表現(xiàn)出較高的性能,一方面得益于DPDK簡單的數(shù)據(jù)包處理流程,另一方面也得益于本文引入的CPU親和性技術(shù),通過將線程綁定CPU核心的方式減少系統(tǒng)調(diào)度帶來的CPU時(shí)間片的浪費(fèi),使得更多的CPU時(shí)間片能夠用于數(shù)據(jù)包的處理.

圖4 數(shù)據(jù)網(wǎng)絡(luò)接收性能對比圖Fig.4 Data network reception performance comparison chart

由此可見,采用本文提出的傳輸機(jī)制進(jìn)行數(shù)據(jù)網(wǎng)絡(luò)傳輸時(shí)相比于傳統(tǒng)的網(wǎng)絡(luò)庫有較大的性能提升.在數(shù)據(jù)網(wǎng)絡(luò)發(fā)送方面,傳統(tǒng)網(wǎng)絡(luò)庫的數(shù)據(jù)網(wǎng)絡(luò)發(fā)送性能瓶頸在2,800MB/s左右,而該機(jī)制能夠滿足不小于5,000MB/s的數(shù)據(jù)網(wǎng)絡(luò)發(fā)送要求.在數(shù)據(jù)網(wǎng)絡(luò)接收方面,在40Gb/s的數(shù)據(jù)源發(fā)送流量的考驗(yàn)下,本文方案可以保證接近100%的數(shù)據(jù)包捕獲率,而傳統(tǒng)的網(wǎng)絡(luò)庫只有50%左右的捕獲率.

6.3 整體性能測試

本節(jié)測試主要針對數(shù)據(jù)流傳輸系統(tǒng)的整體運(yùn)行情況進(jìn)行測試.主要的實(shí)驗(yàn)?zāi)康木褪球?yàn)證組成本文提出的三大模塊是否能夠有機(jī)結(jié)合在一起,實(shí)現(xiàn)數(shù)據(jù)流傳輸功能.為了更加簡便的獲取測試結(jié)果,本文引入了Prometheus和Grafana技術(shù)實(shí)現(xiàn)了監(jiān)控指標(biāo)的獲取和可視化展示[15].測試開始前在接入服務(wù)器上部署數(shù)據(jù)網(wǎng)絡(luò)轉(zhuǎn)發(fā)模塊,在計(jì)算服務(wù)器上部署數(shù)據(jù)網(wǎng)絡(luò)接收模塊和數(shù)據(jù)本地消費(fèi)模塊并開啟雷達(dá)應(yīng)用程序,最后在監(jiān)控服務(wù)器上部署Prometheus和Grafana服務(wù).

本次測試中使用FPGA信號源發(fā)送雷達(dá)數(shù)據(jù),數(shù)據(jù)發(fā)送速率為5Gb/s,數(shù)據(jù)通道數(shù)為8,單個(gè)數(shù)據(jù)包長度為1472字節(jié),UDP格式.數(shù)據(jù)轉(zhuǎn)發(fā)時(shí),源端口號設(shè)置為8000,目的端口號從8881設(shè)置到8888.本次測試中主要收集了各通道的傳輸速率、丟包率等性能指標(biāo),同時(shí)也收集了測試過程中系統(tǒng)大頁內(nèi)存和CPU的使用情況.其中,各項(xiàng)性能指標(biāo)統(tǒng)計(jì)如表3所示.

表3 性能測試結(jié)果統(tǒng)計(jì)Table 3 Statistics of performance test results

通過分析表3可知,在單通道速率為5Gb/s的前提下,通道1和通道4產(chǎn)生了丟包現(xiàn)象,丟包數(shù)分別為147和42.這是由于實(shí)驗(yàn)環(huán)境溫度較高,而實(shí)驗(yàn)中采用的FPGA數(shù)據(jù)源散熱較差,在長時(shí)間壓力測試的情況下容易造成數(shù)據(jù)源不穩(wěn)定的情況,進(jìn)而造成隨機(jī)丟包的現(xiàn)象.但全通道總計(jì)丟包數(shù)僅為189,相對于處理的海量數(shù)據(jù)包可以忽略不計(jì),整個(gè)系統(tǒng)的運(yùn)行較為穩(wěn)定.在不考慮應(yīng)用程序資源占用的情況下,測試過程中接入服務(wù)器和計(jì)算服務(wù)器總體的資源使用情況如表4所示.

表4 系統(tǒng)資源利用情況Table 4 System resource utilization

通過分析表4可知,得益于本文中為多核CPU設(shè)計(jì)的多線程方法,將每個(gè)子任務(wù)交由不同的CPU核心執(zhí)行,降低了單核CPU的計(jì)算壓力,發(fā)揮了多核CPU的優(yōu)勢,CPU核心的利用率達(dá)到了26%.本文中提出的傳輸機(jī)制中采用大頁內(nèi)存代替了傳統(tǒng)內(nèi)存,通過增大操作系統(tǒng)頁面的大小減少了頁面的數(shù)量,降低了緩存丟失的概率,進(jìn)而降低了對內(nèi)存的使用量,僅使用了6.1%的內(nèi)存.本文將DPDK技術(shù)與Flow Director技術(shù)相結(jié)合,利用一張網(wǎng)卡的多個(gè)隊(duì)列進(jìn)行數(shù)據(jù)的并行傳輸,充分利用了網(wǎng)卡的多隊(duì)列特性,提升了網(wǎng)卡帶寬的利用率,測試中的網(wǎng)卡利用率達(dá)到了42.8%,能夠適應(yīng)8通道數(shù)據(jù)的傳輸?shù)囊?

綜上所述,在外部數(shù)據(jù)源輸入的情況下,本文中提出的地面相控陣?yán)走_(dá)數(shù)據(jù)流傳輸機(jī)制能夠充分利用多核CPU優(yōu)勢、降低內(nèi)存空間使用率,充分發(fā)揮網(wǎng)卡的硬件性能.能夠在單通道速率不低于5Gb/s的情況下實(shí)現(xiàn)8路雷達(dá)數(shù)據(jù)的長時(shí)間穩(wěn)定傳輸.

7 結(jié) 論

本文圍繞地面相控陣?yán)走_(dá)數(shù)據(jù)流的傳輸問題,首先分析了數(shù)據(jù)網(wǎng)絡(luò)傳輸技術(shù)的研究現(xiàn)狀,而后基于DPDK技術(shù)提出了面向地面相控陣?yán)走_(dá)數(shù)據(jù)流的傳輸機(jī)制.實(shí)驗(yàn)結(jié)果顯示,在同時(shí)傳輸8路雷達(dá)數(shù)據(jù)流時(shí),本文提出的傳輸機(jī)制相比于傳統(tǒng)Asio網(wǎng)絡(luò)通信庫在網(wǎng)絡(luò)流量性能指標(biāo)方面提升了78%.在發(fā)送流量為40Gb/s時(shí),本文提出的傳輸機(jī)制相比于傳統(tǒng)Asio網(wǎng)絡(luò)通信庫在數(shù)據(jù)包捕獲率性能指標(biāo)方面提升了近80%.能夠支持單機(jī)不小于8路雷達(dá)數(shù)據(jù)流傳輸,且每路雷達(dá)數(shù)據(jù)流的傳輸速率不低于5Gb/s.雖然本文中提出的傳輸機(jī)制能夠在高速的情況下完成地面相控陣?yán)走_(dá)數(shù)據(jù)流的傳輸任務(wù),但是仍然有少量丟包的情況出現(xiàn),如何進(jìn)一步減少丟包數(shù)量,提升數(shù)據(jù)流傳輸?shù)姆€(wěn)定性仍需要進(jìn)一步研究.