絕對乾貨！初學者也能看懂的DPDK解析

騰訊雲加社群發表於2018-09-04

歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~

本文由Willko發表於雲+社群專欄

一、網路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旁路原理：

img
圖片引自Jingjing Wu的文件《Flow Bifurcation on Intel® Ethernet Controller X710/XL710》

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

右邊是DPDK的方式，基於UIO（Userspace I/O）旁路資料。資料從 網路卡 -> DPDK輪詢模式-> DPDK基礎庫 -> 業務

使用者態的好處是易用開發和維護，靈活性好。並且Crash也不影響核心執行，魯棒性強。

DPDK支援的CPU體系架構：x86、ARM、PowerPC（PPC）

DPDK支援的網路卡列表：core.dpdk.org/supported/，我們主流使用Intel 82599（光口）、Intel x540（電口）

四、DPDK的基石UIO

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

UIO原理：

img

要開發使用者態驅動有幾個步驟：

1.開發執行在核心的UIO模組，因為硬中斷只能在核心處理

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

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

五、DPDK核心優化：PMD

DPDK的UIO驅動遮蔽了硬體發出中斷，然後在使用者態採用主動輪詢的方式，這種模式被稱為PMD（Poll Mode Driver）。

UIO旁路了核心，主動輪詢去掉硬中斷，DPDK從而可以在使用者態做收發包處理。帶來Zero Copy、無系統呼叫的好處，同步處理減少上下文切換帶來的Cache Miss。

執行在PMD的Core會處於使用者態CPU100%的狀態

img

網路空閒時CPU長期空轉，會帶來能耗問題。所以，DPDK推出Interrupt DPDK模式。

Interrupt DPDK：

img
圖片引自David Su/Yunhong Jiang/Wei Wang的文件《Towards Low Latency Interrupt Mode 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個引數，比較常見的實現：

static inline uint64_t
rte_rdtsc(void)
{
      uint32_t lo, hi;

      __asm__ __volatile__ (
                 "rdtsc" : "=a"(lo), "=d"(hi)
                 );

      return ((unsigned long long)lo) | (((unsigned long long)hi) << 32);
}
複製程式碼

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

static inline uint64_t
rte_rdtsc(void)
{
	union {
		uint64_t tsc_64;
		struct {
			uint32_t lo_32;
			uint32_t hi_32;
		};
	} tsc;

	asm volatile("rdtsc" :
		     "=a" (tsc.lo_32),
		     "=d" (tsc.hi_32));
	return tsc.tsc_64;
}
複製程式碼

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

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

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

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

5. 編譯執行優化

  1. 分支預測

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

#pragma once

#if !__GLIBC_PREREQ(2, 3)
#    if !define __builtin_expect
#        define __builtin_expect(x, expected_value) (x)
#    endif
#endif

#if !defined(likely)
#define likely(x) (__builtin_expect(!!(x), 1))
#endif

#if !defined(unlikely)
#define unlikely(x) (__builtin_expect(!!(x), 0))
#endif
複製程式碼
  1. CPU Cache預取

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

API文件：doc.dpdk.org/api/rte__pr…

static inline void rte_prefetch0(const volatile void *p)
{
	asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char *)p));
}
複製程式碼
#if !defined(prefetch)
#define prefetch(x) __builtin_prefetch(x)
#endif
複製程式碼

…等等

  1. 記憶體對齊

記憶體對齊有2個好處：

l 避免結構體成員跨Cache Line，需2次讀取才能合併到暫存器中，降低效能。結構體成員需從大到小排序和以及強制對齊。參考《Data alignment: Straighten up and fly right》

#define __rte_packed __attribute__((__packed__))
複製程式碼

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

#ifndef CACHE_LINE_SIZE
#define CACHE_LINE_SIZE 64
#endif

#ifndef aligined
#define aligined(a) __attribute__((__aligned__(a)))
#endif
複製程式碼
  1. 常量優化

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

#define rte_bswap32(x) ((uint32_t)(__builtin_constant_p(x) ?		\
				   rte_constant_bswap32(x) :		\
				   rte_arch_bswap32(x)))
複製程式碼

其中rte_constant_bswap32的實現

#define RTE_STATIC_BSWAP32(v) \
	((((uint32_t)(v) & UINT32_C(0x000000ff)) << 24) | \
	 (((uint32_t)(v) & UINT32_C(0x0000ff00)) <<  8) | \
	 (((uint32_t)(v) & UINT32_C(0x00ff0000)) >>  8) | \
	 (((uint32_t)(v) & UINT32_C(0xff000000)) >> 24))
複製程式碼

5）使用CPU指令

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

static inline uint64_t rte_arch_bswap64(uint64_t _x)
{
	register uint64_t x = _x;
	asm volatile ("bswap %[x]"
		      : [x] "+r" (x)
		      );
	return x;
}
複製程式碼

這個實現，也是GLIBC的實現，先常量優化、CPU指令優化、最後才用裸程式碼實現。畢竟都是頂端程式設計師，對語言、編譯器，對實現的追求不一樣，所以造輪子前一定要先了解好輪子。

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。從專案定位到社群支援力度算比較靠譜的框架。

騰訊雲開源的F-Stack也值得關注一下，開發更簡單，直接提供了POSIX介面。

Seastar也很強大和靈活，核心態和DPDK都隨意切換，也有自己的傳輸協議Seastar Native TCP/IP Stack支援，但是目前還未看到有大型專案在使用Seastar，可能需要填的坑比較多。

我們GBN Gateway專案需要支援L3/IP層接入做Wan閘道器，單機20GE，基於DPDK開發。

問答

如何檢查網路連線？

相關閱讀

把報文再扔回核心，DPDK這樣做

用DPDK rte_ring實現多程式間通訊

低於0.01%的極致Crash率是怎麼做到的？

【每日課程推薦】新加坡南洋理工大學博士，帶你深度學習NLP技術

此文已由作者授權騰訊雲+社群釋出，更多原文請點選

搜尋關注公眾號「雲加社群」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社群！

相關文章