歡迎光臨
每天分享高質量文章

面向初學者的DPDK技術解析

一、網絡IO的處境和趨勢

從我們用戶的使用就可以感受到網速一直在提升,而網絡技術的發展也從1GE/10GE/25GE/40GE/100GE的演變,從中可以得出單機的網絡IO能力必須跟上時代的發展。

1. 傳統的電信領域

IP層及以下,例如路由器、交換機、防火牆、基站等設備都是採用硬體解決方案。基於專用網絡處理器(NP),有基於FPGA,更有基於ASIC的。但是基於硬體的劣勢非常明顯,發生Bug不易修複,不易除錯維護,並且網絡技術一直在發展,例如2G/3G/4G/5G等移動技術的革新,這些屬於業務的邏輯基於硬體實現太痛苦,不能快速迭代。傳統領域面臨的挑戰是急需一套軟體架構的高性能網絡IO開發框架。

2. 雲的發展

私有雲的出現通過網絡功能虛擬化(NFV)共享硬體成為趨勢,NFV的定義是通過標準的服務器、標準交換機實現各種傳統的或新的網絡功能。急需一套基於常用系統和標準服務器的高性能網絡IO開發框架。

3. 單機性能的飆升

網卡從1G到100G的發展,CPU從單核到多核到多CPU的發展,服務器的單機能力通過橫行擴展達到新的高點。但是軟體開發卻無法跟上節奏,單機處理能力沒能和硬體門當戶對,如何開發出與時併進高吞吐量的服務,單機百萬千萬併發能力。即使有業務對QPS要求不高,主要是CPU密集型,但是現在大資料分析、人工智慧等應用都需要在分佈式服務器之間傳輸大量資料完成作業。這點應該是我們互聯網後臺開發最應關註,也最關聯的。

二、Linux + X86網絡IO瓶頸

在數年前曾經寫過《網卡工作原理及高併發下的調優》一文,描述了Linux的收發報文流程。根據經驗,在C1(8核)上跑應用每1W包處理需要消耗1%軟中斷CPU,這意味著單機的上限是100萬PPS(Packet Per Second)。從TGW(Netfilter版)的性能100萬PPS,AliLVS優化了也只到150萬PPS,並且他們使用的服務器的配置還是比較好的。假設,我們要跑滿10GE網卡,每個包64位元組,這就需要2000萬PPS(註:以太網萬兆網卡速度上限是1488萬PPS,因為最小幀大小為84B《Bandwidth, Packets Per Second, and Other Network Performance Metrics》),100G是2億PPS,即每個包的處理耗時不能超過50納秒。而一次Cache Miss,不管是TLB、資料Cache、指令Cache發生Miss,回記憶體讀取大約65納秒,NUMA體系下跨Node通訊大約40納秒。所以,即使不加上業務邏輯,即使純收發包都如此艱難。我們要控制Cache的命中率,我們要瞭解計算機體系結構,不能發生跨Node通訊。

從這些資料,我希望可以直接感受一下這裡的挑戰有多大,理想和現實,我們需要從中平衡。問題都有這些

1.傳統的收發報文方式都必須採用硬中斷來做通訊,每次硬中斷大約消耗100微秒,這還不算因為終止背景關係所帶來的Cache Miss。

2.資料必須從內核態用戶態之間切換拷貝帶來大量CPU消耗,全域性鎖競爭。

3.收發包都有系統呼叫的開銷。

4.內核工作在多核上,為可全域性一致,即使採用Lock Free,也避免不了鎖總線、記憶體屏障帶來的性能損耗。

5.從網卡到業務行程,經過的路徑太長,有些其實未必要的,例如netfilter框架,這些都帶來一定的消耗,而且容易Cache Miss。

三、DPDK的基本原理

從前面的分析可以得知IO實現的方式、內核的瓶頸,以及資料流過內核存在不可控因素,這些都是在內核中實現,內核是導致瓶頸的原因所在,要解決問題需要繞過內核。所以主流解決方案都是旁路網卡IO,繞過內核直接在用戶態收發包來解決內核的瓶頸。

Linux社區也提供了旁路機制Netmap,官方資料10G網卡1400萬PPS,但是Netmap沒廣泛使用。其原因有幾個:

1.Netmap需要驅動的支持,即需要網卡廠商認可這個方案。

2.Netmap仍然依賴中斷通知機制,沒完全解決瓶頸。

3.Netmap更像是幾個系統呼叫,實現用戶態直接收發包,功能太過原始,沒形成依賴的網絡開發框架,社區不完善。

那麼,我們來看看發展了十幾年的DPDK,從Intel主導開發,到華為、思科、AWS等大廠商的加入,核心玩家都在該圈子裡,擁有完善的社區,生態形成閉環。早期,主要是傳統電信領域3層以下的應用,如華為、中國電信、中國移動都是其早期使用者,交換機、路由器、網關是主要應用場景。但是,隨著上層業務的需求以及DPDK的完善,在更高的應用也在逐步出現。

DPDK旁路原理:

左邊是原來的方式資料從 網卡 -> 驅動 -> 協議棧 -> Socket接口 -> 業務

右邊是DPDK的方式,基於UIO(Userspace I/O)旁路資料。資料從 網卡 -> DPDK輪詢樣式-> DPDK基礎庫 -> 業務

用戶態的好處是易用開發和維護,靈活性好。並且Crash也不影響內核運行,魯棒性強。

DPDK支持的CPU體系架構:x86、ARM、PowerPC(PPC)

DPDK支持的網卡串列:https://core.dpdk.org/supported/,我們主流使用Intel 82599(光口)、Intel x540(電口)

四、DPDK的基石UIO

為了讓驅動運行在用戶態,Linux提供UIO機制。使用UIO可以通過read感知中斷,通過mmap實現和網卡的通訊。

UIO原理:

要開發用戶態驅動有幾個步驟:

1.開發運行在內核的UIO模塊,因為硬中斷只能在內核處理

2.通過/dev/uioX讀取中斷

3.通過mmap和外設共享記憶體

五、DPDK核心優化:PMD

DPDK的UIO驅動屏蔽了硬體發出中斷,然後在用戶態採用主動輪詢的方式,這種樣式被稱為PMD(Poll Mode Driver)。

UIO旁路了內核,主動輪詢去掉硬中斷,DPDK從而可以在用戶態做收發包處理。帶來Zero Copy、無系統呼叫的好處,同步處理減少背景關係切換帶來的Cache Miss。

運行在PMD的Core會處於用戶態CPU100%的狀態

網絡空閑時CPU長期空轉,會帶來能耗問題。所以,DPDK推出Interrupt DPDK樣式。

Interrupt DPDK:

它的原理和NAPI很像,就是沒包可處理時進入睡眠,改為中斷通知。並且可以和其他行程共享同個CPU Core,但是DPDK行程會有更高調度優先級。

六、DPDK的高性能代碼實現

1. 採用HugePage減少TLB Miss

預設下Linux採用4KB為一頁,頁越小記憶體越大,頁表的開銷越大,頁表的記憶體占用也越大。CPU有TLB(Translation Lookaside Buffer)成本高所以一般就只能存放幾百到上千個頁表項。如果行程要使用64G記憶體,則64G/4KB=16000000(一千六百萬)頁,每頁在頁表項中占用16000000 * 4B=62MB。如果用HugePage採用2MB作為一頁,只需64G/2MB=2000,數量不在同個級別。

而DPDK採用HugePage,在x86-64下支持2MB、1GB的頁大小,幾何級的降低了頁表項的大小,從而減少TLB-Miss。並提供了記憶體池(Mempool)、MBuf、無鎖環(Ring)、Bitmap等基礎庫。根據我們的實踐,在資料平面(Data Plane)頻繁的記憶體分配釋放,必須使用記憶體池,不能直接使用rte_malloc,DPDK的記憶體分配實現非常簡陋,不如ptmalloc。

2. SNA(Shared-nothing Architecture)

軟體架構去中心化,儘量避免全域性共享,帶來全域性競爭,失去橫向擴展的能力。NUMA體系下不跨Node遠程使用記憶體。

3. SIMD(Single Instruction Multiple Data)

從最早的mmx/sse到最新的avx2,SIMD的能力一直在增強。DPDK採用批量同時處理多個包,再用向量編程,一個周期內對所有包進行處理。比如,memcpy就使用SIMD來提高速度。

SIMD在游戲後臺比較常見,但是其他業務如果有類似批量處理的場景,要提高性能,也可看看能否滿足。

4. 不使用慢速API

這裡需要重新定義一下慢速API,比如說gettimeofday,雖然在64位下通過vDSO已經不需要陷入內核態,只是一個純記憶體訪問,每秒也能達到幾千萬的級別。但是,不要忘記了我們在10GE下,每秒的處理能力就要達到幾千萬。所以即使是gettimeofday也屬於慢速API。DPDK提供Cycles接口,例如rte_get_tsc_cycles接口,基於HPET或TSC實現。

在x86-64下使用RDTSC指令,直接從暫存器讀取,需要輸入2個引數,比較常見的實現:

這麼寫邏輯沒錯,但是還不夠極致,還涉及到2次位運算才能得到結果,我們看看DPDK是怎麼實現:

巧妙的利用C的union共享記憶體,直接賦值,減少了不必要的運算。但是使用tsc有些問題需要面對和解決

1) CPU親和性,解決多核跳動不精確的問題

2) 記憶體屏障,解決亂序執行不精確的問題

3) 禁止降頻和禁止Intel Turbo Boost,固定CPU頻率,解決頻率變化帶來的失準問題

5. 編譯執行優化

1) 分支預測

現代CPU通過pipeline、superscalar提高並行處理能力,為了進一步發揮並行能力會做分支預測,提升CPU的並行能力。遇到分支時判斷可能進入哪個分支,提前處理該分支的代碼,預先做指令讀取編碼讀取暫存器等,預測失敗則預處理全部丟棄。我們開發業務有時候會非常清楚這個分支是true還是false,那就可以通過人工干預生成更緊湊的代碼提示CPU分支預測成功率。

2) CPU Cache預取

Cache Miss的代價非常高,回記憶體讀需要65納秒,可以將即將訪問的資料主動推送的CPU Cache進行優化。比較典型的場景是鏈表的遍歷,鏈表的下一節點都是隨機記憶體地址,所以CPU肯定是無法自動預加載的。但是我們在處理本節點時,可以通過CPU指令將下一個節點推送到Cache里。

…等等

3) 記憶體對齊

記憶體對齊有2個好處:

l 避免結構體成員跨Cache Line,需2次讀取才能合併到暫存器中,降低性能。結構體成員需從大到小排序和以及強制對齊。

l 多執行緒場景下寫產生False sharing,造成Cache Miss,結構體按Cache Line對齊

4) 常量優化

常量相關的運算的編譯階段完成。比如C++11引入了constexp,比如可以使用GCC的__builtin_constant_p來判斷值是否常量,然後對常量進行編譯時得出結果。舉例網絡序主機序轉換

其中rte_constant_bswap32的實現

5)使用CPU指令

現代CPU提供很多指令可直接完成常見功能,比如大小端轉換,x86有bswap指令直接支持了。

器,對實現的追求不一樣,所以造輪子前一定要先瞭解好輪子。

Google開源的cpu_features可以獲取當前CPU支持什麼特性,從而對特定CPU進行執行優化。高性能編程永無止境,對硬體、內核、編譯器、開發語言的理解要深入且與時俱進。

七、DPDK生態

對我們互聯網後臺開發來說DPDK框架本身提供的能力還是比較裸的,比如要使用DPDK就必須實現ARP、IP層這些基礎功能,有一定上手難度。如果要更高層的業務使用,還需要用戶態的傳輸協議支持。不建議直接使用DPDK。

目前生態完善,社區強大(一線大廠支持)的應用層開發專案是FD.io(The Fast Data Project),有思科開源支持的VPP,比較完善的協議支持,ARP、VLAN、Multipath、IPv4/v6、MPLS等。用戶態傳輸協議UDP/TCP有TLDK。從專案定位到社區支持力度算比較靠譜的框架。

來源:悅碼

 

赞(0)

分享創造快樂