深入理解DPDK程序设计|Linux网络2.0
hi，大家好，由于移動互聯網不斷發展，導致網絡流量徒增，推動著網絡技術不斷地發展，而CPU的運行頻率基本停留在10年前的水平，為了迎接超高速網絡技術的挑戰，軟件也需要大幅度創新，結合硬件技術的發展，DPDK（Data Plane Development Kit），一個以軟件優化為主的數據面技術應時而生，它為今天NFV技術的發展提供了絕佳的平臺可行性。
NFV：Network functions virtualization，網絡功能虛擬化。
同時作為技術人員，我們可以從中DPDK學習大量的高性能編程技巧和代碼優化技巧，包括高性能軟件架構最佳實踐、高效數據結構設計和內存優化技巧、應用程序性能分析以及網絡性能優化的技巧。
文章目錄
一、 ?網絡IO的處境和趨勢
二、 ?Linux + x86網絡IO瓶頸
三、 ?DPDK的基本原理
四、 ?DPDK的基石UIO
五、 ?DPDK核心優化：PMD
六、 ?DPDK的高性能代碼實現
七、 ?????????????????????DPDK生態
八、 ?高性能編程技術和代碼優化技術(總結)
本文《GBN手札 - 一文看懂DPDK》首次發表在騰訊內部KM平臺，大量修改更新后再次發表在公眾號平臺
一、網絡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瓶頸
根據經驗，在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通訊。
從這些數據，我希望可以直接感受一下這里的挑戰有多大，理想和現實，我們需要從中平衡。問題都有這些：
傳統的收發報文方式都必須采用硬中斷來做通訊，每次硬中斷大約消耗100微秒，這還不算因為終止上下文所帶來的Cache Miss。
數據必須從內核態用戶態之間切換拷貝帶來大量CPU消耗，全局鎖競爭。
Linux協議棧處理路徑長，多核擴展性不足，系統調用開銷大。
內核工作在多核上，為可全局一致，即使采用Lock Free，也避免不了鎖總線、內存屏障帶來的性能損耗。
從網卡到業務進程，經過的路徑太長，有些其實未必要的，例如netfilter框架，這些都帶來一定的消耗，而且容易Cache Miss。
三、DPDK的基本原理
從前面的分析可以得知IO實現的方式、內核的瓶頸，以及數據流過內核存在不可控因素，這些都是在內核中實現，內核是導致瓶頸的原因所在，要解決問題需要繞過內核。所以主流解決方案都是旁路網卡IO，繞過內核直接在用戶態收發包來解決內核的瓶頸。
Linux社區也提供了旁路機制Netmap，官方數據10G網卡1400萬PPS，但是Netmap沒廣泛使用。其原因有幾個：
Netmap需要驅動的支持，即需要網卡廠商認可這個方案。
Netmap仍然依賴中斷通知機制，沒完全解決瓶頸。
Netmap更像是幾個系統調用，實現用戶態直接收發包，功能太過原始，沒形成依賴的網絡開發框架，社區不完善。
那么，我們來看看發展了十幾年的DPDK，從Intel主導開發，到華為、思科、AWS等大廠商的加入，核心玩家都在該圈子里，擁有完善的社區，生態形成閉環。早期，主要是傳統電信領域3層以下的應用，如華為、中國電信、中國移動都是其早期使用者，交換機、路由器、網關是主要應用場景。但是，隨著上層業務的需求以及DPDK的完善，在更高的應用也在逐步出現，尤其當前云計算領域（網絡吞吐量巨大），已經成為云網絡主要的核心技術之一。
DPDK旁路原理
左邊是內核協議棧：
?網卡 -> 驅動 -> 協議棧 -> Socket接口 -> 業務
右邊是DPDK的方式（基于UIO（Userspace I/O）旁路數據）：
網卡 -> DPDK輪詢模式-> DPDK基礎庫 -> 業務
用戶態的好處是易用開發和維護，靈活性好。并且Crash也不影響內核運行，魯棒性強。
而DPDK不光是bypass 內核協議棧，還無所不及地采用各種手段，把凡是能夠影響的網絡IO性能的瓶頸點都做了極致的優化。
DPDK架構
核心模塊
環境抽象層
? ? ? 環境抽象層 (EAL) 提供了一個通用接口，該接口對應用程序和庫隱藏了環境細? ? ? ? 節。EAL 提供的服務是：
DPDK 加載和啟動
支持多進程和多線程執行類型
核心關聯/分配程序
系統內存分配/解除分配
原子/鎖操作
時間參考
PCI總線訪問
跟蹤和調試功能
CPU特性識別
中斷處理
報警操作
內存管理（malloc）
環管理器 (librte_ring)
環形結構在有限大小的表中提供了一個無鎖的多生產者、多消費者 FIFO API。它比無鎖隊列有一些優勢；更容易實施，適應批量操作，速度更快。環由內存池管理器 (librte_mempool)?使用，并可用作核心和/或邏輯核心上連接在一起的執行塊之間的通用通信機制。
內存池管理器 (librte_mempool)
內存池管理器負責分配內存中的對象池。池由名稱標識并使用環來存儲空閑對象，它提供了一些其他可選服務，例如每核對象緩存和對齊助手，以確保填充對象以在所有 RAM 通道上均勻分布它們。
網絡數據包緩沖區管理 (librte_mbuf)
mbuf 庫提供了創建和銷毀緩沖區的功能，DPDK 應用程序可以使用這些緩沖區來存儲消息緩沖區。消息緩沖區在啟動時創建并存儲在內存池中，使用 DPDK 內存池庫。該庫提供了一個 API 來分配/釋放 mbuf，操作用于承載網絡數據包的數據包緩沖區。
定時器管理器 (librte_timer)
該庫為 DPDK 執行單元提供定時器服務，提供異步執行功能的能力。它可以是周期性的函數調用，也可以是一次性調用。它使用環境抽象層 (EAL) 提供的計時器接口來獲取精確的時間參考，并且可以根據需要在每個內核的基礎上啟動。
?以太網* 輪詢模式驅動程序架構
DPDK 包括用于 1 GbE、10 GbE 和 40 GbE 的輪詢模式驅動程序 (PMD)，以及半虛擬化的 virtio 以太網控制器，這些控制器旨在在沒有異步、基于中斷的信號機制的情況下工作。
數據包轉發算法支持
DPDK 包括哈希（librte_hash）和最長前綴匹配（LPM，librte_lpm）庫，以支持相應的數據包轉發算法。
librte_net
librte_net 庫是 IP 協議定義和便利宏的集合。它基于 FreeBSD* IP 堆棧中的代? ? 碼，包含協議編號（用于 IP 標頭）、IP 相關宏、IPv4/IPv6 標頭結構以及 TCP、UDP 和 SCTP 標頭結構。
優化技術
PMD用戶態驅動，使用無中斷方式直接操作網卡的接收和發送隊列；
采用HugePage減少TLB Miss；
DPDK采用向量SIMD指令優化性能；
CPU親緣性和獨占；
內存對齊：根據不同存儲硬件的配置來優化程序，確保對象位于不同channel和rank的起始地址，這樣能保證對象并并行加載，性能也能夠得到極大的提升；
Cache對齊，提高cache訪問效率：
NUMA親和，提高numa內存訪問性能；
減少進程上下文切換：保證活躍進程數目不超過CPU個數；減少堵塞函數的調用，盡量采樣無鎖數據結構；
利用空間局部性，采用預取Prefetch，在數據被用到之前就將其調入緩存，增加緩存命中率；
充分挖掘網卡的潛能：借助現代網卡支持的分流（RSS, FDIR）和卸載（TSO，chksum）等特性；
DPDK支持的CPU體系架構
x86、ARM、PowerPC（PPC）
DPDK支持的網卡列表
https://core.dpdk.org/supported
四、DPDK的基石UIO
為了讓驅動運行在用戶態，Linux提供UIO機制。使用UIO可以通過read感知中斷，通過mmap實現和網卡的通訊。
UIO（Userspace I/O）是運行在用戶空間的I/O技術。Linux系統中一般的驅動設備都是運行在內核空間，而在用戶空間用應用程序調用即可，而UIO則是將驅動的很少一部分運行在內核空間，而在用戶空間實現驅動的絕大多數功能！使用UIO可以避免設備的驅動程序需要隨著內核的更新而更新的問題.通過UIO的運行原理圖可以看出,用戶空間下的驅動程序比運行在內核空間的驅動要多得多,UIO框架下運行在內核空間的驅動程序所做的工作比較簡單。
UIO原理：
要開發用戶態驅動有幾個步驟：
???1.開發運行在內核的UIO模塊（分配和記錄設備需要的資源和注冊uio設備），因為硬中斷只能在內核處理；
2.通過/dev/uioX讀取中斷；
3.通過mmap和外設共享內存，實現零拷貝；
五、DPDK核心優化：PMD
UIO旁路了內核，主動輪詢去掉硬中斷，DPDK從而可以在用戶態做收發包處理。帶來Zero Copy、無系統調用的好處，同步處理減少上下文切換帶來的Cache Miss。
運行在PMD的Core會處于用戶態CPU100%的狀態
網絡空閑時CPU長期空轉，會帶來能耗問題。所以，DPDK推出Interrupt DPDK模式。
Interrupt DPDK：
圖片引自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個參數，比較常見的實現：
這么寫邏輯沒錯，但是還不夠極致，還涉及到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里。
API文檔：https://doc.dpdk.org/api/rte__prefetch_8h.html
3) 內存對齊
內存對齊有2個好處：
3.1 避免結構體成員跨Cache Line，需2次讀取才能合并到寄存器中，降低性能。結構體成員需從大到小排序和以及強制對齊。
參考《Data alignment: Straighten up and fly right》
3.2 多線程場景下寫產生False sharing，造成Cache Miss，結構體按Cache Line對齊
4) 常量優化
常量相關的運算的編譯階段完成。比如C++11引入了constexp，比如可以使用GCC的__builtin_constant_p來判斷值是否常量，然后對常量進行編譯時得出結果。舉例網絡序主機序轉換
其中rte_constant_bswap32的實現
5）使用CPU指令
現代CPU提供很多指令可直接完成常見功能，比如大小端轉換，x86有bswap指令直接支持了。
這個實現，也是GLIBC的實現，先常量優化、CPU指令優化、最后才用裸代碼實現。畢竟都是頂端程序員，對語言、編譯器，對實現的追求不一樣，所以造輪子前一定要先了解好輪子。
Google開源的cpu_features可以獲取當前CPU支持什么特性，從而對特定CPU進行執行優化。高性能編程永無止境，對硬件、內核、編譯器、開發語言的理解要深入且與時俱進。
七、DPDK生態
對我們互聯網后臺開發來說DPDK框架本身提供的能力還是比較裸的，比如要使用DPDK就必須實現TCP/IP協議棧（ARP，IP，TCP/UDP, socket等）這些基礎功能，有一定上手難度。如果要更高層的業務使用，還需要用戶態的協議棧支持。不建議直接使用DPDK。
應用
目前生態完善，社區強大（一線大廠支持）的應用層開發項目是FD.io（The Fast Data Project），有思科開源支持的VPP，比較完善的協議支持，ARP、VLAN、Multipath、IPv4/v6、MPLS等。用戶態傳輸協議UDP/TCP有TLDK。從項目定位到社區支持力度算比較靠譜的框架。
Fd.io: The Universal Dataplane
FD.io（快速數據 - 輸入/輸出）是多個項目和庫的集合，用于擴展基于數據平面開發套件 (DPDK) 的應用，以在通用硬件平臺上支持靈活、可編程和可組合的服務。FD.io 為軟件定義基礎設施開發人員社區提供了一個登陸站點，其中包含多個項目：
促進基于軟件的數據包處理的創新，以創建適用于許多架構（x86、ARM、 PowerPC）和部署環境（裸機、VM、容器）。
騰訊云開源的F-Stack也值得關注一下，開發更簡單，直接提供了POSIX接口。
F-Stack是一個基于DPDK的開源高性能網絡框架，具有以下特點：
網卡滿載時可以達到的超高網絡性能：1000萬并發連接，500萬RPS，100萬CPS。
移植FreeBSD 11.01用戶空間堆棧，提供完整的堆棧功能，并刪減了大量無關功能。這大大提高了網絡性能。
支持Nginx、Redis等成熟應用。服務可以輕松使用 F-Stack。
易于擴展的多進程架構。
提供微線程接口。各種有狀態應用程序可以輕松使用 F-Stack 來獲得高性能，而無需處理復雜的異步邏輯。
提供 Epoll/Kqueue 接口，允許多種應用輕松使用 F-Stack。
Seastar也很強大和靈活，內核態和DPDK都隨意切換，也有自己的傳輸協議Seastar Native TCP/IP Stack支持，但是目前還未看到有大型項目在使用Seastar，可能需要填的坑比較多。
?Seastar 目前專注于高吞吐量、低延遲的 I/O 密集型應用程序。
Pedis?: Redis 兼容的數據結構存儲
Scylla：NoSQL 列存儲數據庫，以 10 倍的吞吐量與 Apache Cassandra 兼容
Seastar HTTPD：網絡服務器
Seastar Memcached：Memcache 鍵值存儲的快速服務器
Open vSwitch?(OVS)高性能開源虛擬交換機, 可以利用DPDK這些功能繞過 Linux 內核OVS 處理,增強OVS的IO性能，官方數據顯示，可以提高9倍以上的性能提升.
八、高性能編程技術和代碼優化
性能評估公式
IPP?表示代碼的復雜程度，IPC?表示代碼執行的效率
2G主頻CPU處理10G網卡達到線速?2GHz/14.8Mpps =134 clock cycles
1.用戶空間輪詢
減少中斷帶來開銷；
減少系統調用帶來開銷；
零拷貝減少內存拷貝的時間；
輪詢 Polling,busy looping 提供了I/O批量處理的可能性；
避免中斷性能瓶頸是DPDK提升數據包處理速度的關鍵之一；
2.多核CPU性能優化
RSS硬件隊列；
CPU獨占：獨占CPU資源，減少調度影響，提高系統性能；
CPU綁定：減少CPU上下文切換，提高系統性能；
中斷親和 :?中斷負載均衡，減輕其他CPU負擔，提高系統性能；
進程親和：減少CPU上下文切換，提高系統性能；
中斷隔離：減少中斷對CPU調度影響，提高系統性能；
Per CPU：Per-CPU是基于空間換時間的方法, 讓每個CPU都有自己的私有數據段(放在L1中),并將一些變量私有化到?每個CPU的私有數據段中. 單個CPU在訪問自己的私有數據段時, 不需要考慮其他CPU之間的競爭問題,也不存在同步的問題. ?注意只有在該變量在各個CPU上邏輯獨立時才可使用；
3. 鎖優化
無鎖數據結構，將并發最大化；
Per-CPU設計，盡量避免資源競爭；
采用RCU機制，讀寫共享數據可以無鎖并行；
? ? ? ?深入理解RCU|核心原理
spinlock，采用非阻塞鎖，防止上下文切換導致cache miss；
采用CAS原子操作(Compare and Swap)進行無鎖設計；
4.批量處理
輪詢機制允許一次接收或發送多個報文；
批量處理分攤的接收或發送操作本身的開銷；
絕大部分報文需要做相同或相似的計算處理，意味著相同的指令會被反復地執行，報文的批量計算分攤了函數調用的上下文切換，堆棧的初始化等等開銷，同時大大減少了l1i cache miss
對于某一個函數，l1icache miss?僅僅發生在第一個報文被處理的時刻
批量計算提供了更好的代碼優化可能性（數據預取，多重循環等）
5.Cache優化
CPU的速度遠遠大于RAM的速度
程序在運行時具有局部性規律
? ? ? ? 時間局部性，很快還會訪問
? ? ? ? 空間局部性，相鄰也會訪問
不同級別cache速度差異?L1 > L2 > L3
減少Cache Miss是提升性能的關鍵
Cache?層次化結構
?
iCacheMiss?常常被忽略
? ? ? ?更優的代碼，編譯器優化選項
? ? ? ?更小的代碼尺寸
? ? ? ?更好的代碼布局-?分支預測
代碼布局影響iCache命中率
????????????B 段代碼較少會被調用
Cache一致性問題
原則是避免多個核訪問同一個內存地址或數據結構
在數據結構上，每個核都有獨立的數據結構
多個核訪問同一個網卡：每個核都創建單獨的接收隊列和發送隊列
6. 代碼優化技巧
Cache Line 對齊，減少dCache miss，?避免偽共享；
數據預取，減少dCache miss， prefetch 指令；
分支預測，優化代碼布局，?提高CPU流水線效率；??????
函數內聯，減少函數調用開銷；
CPU擴展指令集SIMD：sse,avx，減少指令數量，最大化的利用一級緩存訪存的帶寬；
多重循環處理報文，更好地優化CPU流水線；
編譯器優化；
更新優化請閱讀：
Linux性能優化全景指南
????????????????????????參考
GBN手札 - 一文看懂DPD
https://feisky.gitbooks.io/sdn
https://www.dpdk.org/
http://doc.dpdk.org/guides/prog_guide/index.html
最后
DPDK的內容遠不止如此，如果對DPDK感興趣可以參考更多內容:
DPDK官網
https://www.dpdk.org/
DPDK源碼
https://github.com/DPDK/dpdk
DPDK編程指南
http://doc.dpdk.org/guides/prog_guide/index.html
經典書籍推薦
《深入淺出DPDK》
- END -
看完一鍵三連在看，轉發，點贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
圖解Linux 內核TCP/IP 協議棧實現|Linux網絡硬核系列
Linux性能優化全景指南
深入理解RCU|核心原理
總結
以上是生活随笔為你收集整理的深入理解DPDK程序设计|Linux网络2.0的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： TCP的FIN_WAIT1状态理解|深入
- 下一篇： 吐血整理 | 肝翻 Linux 进程调度