一、DPDK基礎原理IntelDPDK全稱IntelDataPlaneDevelopmentKit，是intel提供的數據平面開發工具集，為Intelarchitecture（IA）處理器架構下用戶空間高效的數據包處理提供庫函數和驅動的支持，它不同于Linux系統以通用性設計為目的，而是專注于網絡應用中數據包的高性能處理。DPDK應用程序是運行在用戶空間上利用自身提供的數據平面庫來收發數據包，繞過了Linux內核協議棧對數據包處理過程。Linux內核將DPDK應用程序看作是一個普通的用戶態進程，包括它的編譯、連接和加載方式和普通程序沒有什么兩樣。DPDK程序啟動后只能有一個主線程，然后創建一些子線程并綁定到指定CPU核心上運行。1.1產業背景因特網和其他互聯網必須承載的通信量在持續增長和變化。如今，實時響應的萬維網的廣泛使用和音頻、圖像、視頻的使用增長，驅動了服務質量需求的增長。為了應對這種增長，TCP/IP體系結構發展了QoS（服務質量）以支持各種類型的擁有各種服務質量需求的通信量。數據平面(DataPlane)是QoS框架的三平面之一，承擔了通信中分組的隊列管理，排隊調度，擁塞避免等直接在數據流上進行操作的機制，對提高網絡通信的效率起著至關重要的作用。在此基礎上，人們期望用更低的成本和更短的產品開發周期來提供多樣的網絡單元與豐富的功能，如應用處理、控制處理、包處理、信號處理等。為了適應這一新的產業趨勢，基于Intelx86架構的DPDK面世了。DPDK是一個linux基金會的開源項目。開發DPDK的主要目的，是在數據平面應用中為快速的數據包處理提供一個簡單而完善的架構。在理解此工具集之后，開發人員可以以此為基礎進行新的原型設計，或簡單地為我所用。DPDK架構通過創建EAL(EnvironmentAbstractionLayer,環境抽象層)來為不同的工作環境創造函數庫集，創建后開發者即可把自己的應用與函數庫進行鏈接。該架構也包含跟蹤調試，PCIe總線接入等功能，并有相關樣例幫助開發者學習如何使用這些功能。1.2工作環境DPDK的環境抽象層向應用與函數庫隱藏了底層環境的細節，因而能擴展到任何處理器上使用。就操作系統來說，它提供了對Linux和FreeBSD的支持。1.3工作原理DPDK使用了輪詢(polling)而不是中斷來處理數據包。在收到數據包時，經DPDK重載的網卡驅動不會通過中斷通知CPU，而是直接將數據包存入內存，交付應用層軟件通過DPDK提供的接口來直接處理，這樣節省了大量的CPU中斷時間和內存拷貝時間。1.4關鍵技術環境抽象層DPDK的創造的環境抽象層(EAL,EnvironmentAbstractionLayer)主要負責對計算機底層資源（如硬件和內存空間）的訪問，并對提供給用戶的接口實施了實現細節的封裝。其初始化例程決定了如何分配這些資源（PCI設備、計時器、控制臺等）。EAL提供的典型服務包括：加載和啟動DPDK：DPDK及其應用程序會被鏈接為單一應用，因此需要通過某種方式進行加載DPDK。核關聯/分配過程：EAL提供了將執行單元分配給特定核并創建執行實例的機制。預留系統內存：EAL為預留不同的內存區域提供便利，例如用于設備交互的物理內存區域。抽象PCI地址：EAL提供了訪問PCI地址空間的接口。跟蹤和調試功能：日志、堆棧轉儲等。實用的功能：libc中所沒有提供的自旋鎖和原子計數器。CPU功能識別：在運行時確定CPU是否支持特定功能，確定當前CPU是否支持編譯產生的二進制指令集。中斷處理：向特定中斷源注冊/注銷回調的接口。時鐘功能：用于設置/刪除在特定時間運行的回調函數接口。輪詢模式驅動DPDK包括1Gb,10Gb,40Gb和半虛擬化抽象層的輪詢模式驅動(PMD,PollModeDriver)。PMD由用戶空間的特定的驅動程序提供的API組成，用于對設備和它們相應的隊列進行設置。拋棄了基于中斷的異步信號發送機制為該架構帶來很大的開銷節省。避免中斷性能瓶頸是DPDK提升數據包處理速度的關鍵之一。DPDK環境為數據包處理應用考慮了兩種模型：運行至完成(run-to-completion)模型和管道(pipeline)模型。在運行至完成模型中，一個API向某個特定端口的接收描述符環輪詢以接收數據包。接著這個數據包在同一個核上被處理，之后被一個發送用API放到端口的傳輸描述符環上；在管道模型中，一個核心會通過API對一個或多個端口的接收描述符環進行輪詢，數據包通過環被接收和傳遞給另一個核心，然后在這個核心上被處理，之后可能被發送用API放到端口的傳輸描述符環上。運行至完成是一個同步模型，每個指派給DPDK的邏輯核心執行如下所示的循環：通過PMD接收用API來提取輸出數據包根據轉發，一一處理收到的數據包通過PMD發送用API發送輸出數據包相反，管道模型是一個異步模型，有的邏輯核心只執行數據包提取，而有的只執行處理，收到的數據包在這些邏輯核心之間通過環來傳遞。提取核心執行如下的循環：通過PMD接收用API來提取輸出數據包通過隊列提供數據包給處理核心處理核心執行如下的循環：從隊列中提取數據包根據重傳（如果被轉發）處理數據包為了避免不必要的中斷性能瓶頸，執行環境禁止任何異步通知機制的使用。在任何需要或合適的時候，異步通信都應盡可能采用環的方式。在多核環境中避免鎖競爭是一個重要的問題。為了處理這個問題，PMD被設計為可以盡可能地在單核私有資源下工作。例如，PMD為每個核心每個端口提供一個單獨的隊列。同樣的，每個端口的接收隊列只會被指派給唯一一個邏輯核心并接收它的輪詢。值得回顧的是在DPDK2022年底正式發布的年終版本22.11中，芯啟源代碼貢獻率位居全球第四。前六名分別為Intel、Marvell、Nvidia、Corigine、RedHat、Huawei，排名如下：什么是開源社區？

開源社區又稱開放源代碼社區，是一個由開發者，用戶和社區成員組成的社群，致力于開發和維護開源軟件，其開放性和透明度使任何人都可以自由地查看、復制、使用和修改軟件源代碼，為開發人員、用戶和組織提供了一種相互支持和協作的方式。社區化開發強調各個企業和個人在開發過程中共享代碼和資源，芯啟源采用此種方式，將DPU軟件引入到DPDK驅動的開發中，使得芯啟源DPU軟件得到了全球許多開發者和使用者的廣泛支持。這種社區化的開發方式，讓產品開發者可以更好地集中精力于核心功能的開發，同時也能夠借助社區力量，實現更好的技術積累和資源共享。DPDK開源社區DPDK、OVS和Linux等開源社區是開發網絡、云計算和操作系統等眾多領域的重要技術平臺，其社區貢獻可以加速開源技術的發展創新，降低成本，提高可持續性。其中，DPDK開源社區是當前在高速數據處理領域的前沿社區，是用戶態網絡數據處理性能和吞吐方面的權威。

DPDK(DataPlaneDevelopmentKit)是一個用于加速數據平面軟件包處理的工具包，它的基礎技術是以CPU為中心的快速數據包處理，適合云計算平臺、網絡功能虛擬化和軟件定義網絡等領域的使用。對于個人、企業和組織來說，參與DPDK開源項目可以通過向其貢獻新功能、修復錯誤和提出有價值的想法以改善軟件模塊，同時也受益于DPDK的高效性和靈活性，可實現更快地轉換、更高的速度和更低的延遲等優點。芯啟源DPU

隨著技術的不斷進步和應用場景的不斷拓展，大量的企業和開發者面臨著數據處理和網絡傳輸方面的巨大挑戰，為了解決這些問題，DPU應運而生。

DPU（DataProcessingUnit）作為一種面向先進計算，以提升基礎數據任務效能為核心的可編程專用處理器，可卸載網絡、存儲、安全等業務對CPU的需求，解決了高帶寬、低延遲、數據密集的計算場景的算力困境。芯啟源DPU的成功離不開社區化開發方式的支持，眾多企業和個人通過社區共同參與到開發過程中，共享資源和代碼，共同推動了產品的改進和優化。

在DPDK22.11年終版本中，芯啟源提交了完整的DPURTE_FLOW卸載方案，這使得芯啟源DPU成為國內目前唯一一款被DPDK原生版本支持流表卸載的同類產品。同時，芯啟源在DPDK社區2022年度代碼貢獻率在中國所有科技公司中名列第一，展現了深厚的技術功力。二、DPDK技術簡介2.1軟件架構DPDK的組成架構如下圖所示，相關技術原理概述如下：圖中，在最底部的內核態（LinuxKernel）DPDK有兩個模塊：KNI與IGB_UIO。其中，KNI提供給用戶一個使用Linux內核態的協議棧，以及傳統的Linux網絡工具（如ethtool,ifconfig）。IGB_UIO（igb_uio.ko和kni.ko.IGB_UIO）則借助了UIO技術，在初始化過程中將網卡硬件寄存器映射到用戶態。如圖所示，DPDK的上層用戶態由很多庫組成，主要包括核心部件庫（CoreLibraries）、平臺相關模塊(Platform)、網卡輪詢模式驅動模塊（PMD-Natives&Virtual）、QoS庫、報文轉發分類算法（Classify）等幾大類，用戶應用程序可以使用這些庫進行二次開發，下面分別簡要介紹。核心部件庫該模塊構成的運行環境是建立在Linux上，通過環境抽象層(EAL)的運行環境進行初始化，包括：HugePage內存分配、內存/緩沖區/隊列分配與無鎖操作、CPU親和性綁定等；其次，EAL實現了對操作系統內核與底層網卡I/O操作的屏蔽（I/O旁路了內核及其協議棧），為DPDK應用程序提供了一組調用接口，通過UIO或VFIO技術將PCI設備地址映射到用戶空間，方便了應用程序調用，避免了網絡協議棧和內核切換造成的處理延遲。另外，核心部件還包括創建適合報文處理的內存池、緩沖區分配管理、內存拷貝、以及定時器、環形緩沖區管理等。平臺相關模塊其內部模塊主要包括KNI、能耗管理以及IVSHMEM接口。其中，KNI模塊主要通過kni.ko模塊將數據報文從用戶態傳遞給內核態協議棧處理，以便用戶進程使用傳統的socket接口對相關報文進行處理；能耗管理則提供了一些API，應用程序可以根據收包速率動態調整處理器頻率或進入處理器的不同休眠狀態；另外，IVSHMEM模塊提供了虛擬機與虛擬機之間，或者虛擬機與主機之間的零拷貝共享內存機制，當DPDK程序運行時，IVSHMEM模塊會調用核心部件庫API，把幾個HugePage映射為一個IVSHMEM設備池，并通過參數傳遞給QEMU，這樣，就實現了虛擬機之間的零拷貝內存共享。輪詢模式驅動模塊PMD相關API實現了在輪詢方式下進行網卡報文收發，避免了常規報文處理方法中因采用中斷方式造成的響應延遲，極大提升了網卡收發性能。此外，該模塊還同時支持物理和虛擬化兩種網絡接口，從僅僅支持Intel網卡，發展到支持Cisco、Broadcom、Mellanox、Chelsio等整個行業生態系統,以及基于KVM、VMWARE、XEN等虛擬化網絡接口的支持。DPDK還定義了大量API來抽象數據平面的轉發應用，如ACL、QoS、流分類和負載均衡等。并且，除以太網接口外，DPDK還在定義用于加解密的軟硬件加速接口（Extensions）。2.2巨頁技術處理器的內存管理包含兩個概念：物理內存和虛擬內存。Linux操作系統里面整個物理內存按幀（frames）來進行管理，虛擬內存按照頁（page）來進行管理。內存管理單元（MMU）完成從虛擬內存地址到物理內存地址的轉換。內存管理單元進行地址轉換需要的信息保存在一個叫頁表（pagetable）的數據結構里面，頁表查找是一種極其耗時的操作。為了減少頁表的查找過程，Intel處理器實現了一塊緩存來保存查找結果，這塊緩存被稱為TLB（TranslationLookasideBuffer），它保存了虛擬地址到物理地址的映射關系。所有虛擬地址在轉換為物理地址以前，處理器會首先在TLB中查找是否已經存在有效的映射關系，如果沒有發現有效的映射，也就是TLSmiss，處理器再進行頁表的查找。頁表的查找過程對性能影響極大，因此需要盡量減少TLBmiss的發生。x86處理器硬件在缺省配置下，頁的大小是4K，但也可以支持更大的頁表尺寸，例如2M或1G的頁表。使用了大頁表功能后，一個TLB表項可以指向更大的內存區域，這樣可以大幅減少TLBmiss的發生。早期的Linux并沒有利用x86硬件提供的大頁表功能，僅在Linux內核2.6.33以后的版本，應用軟件才可以使用大頁表功能，具體的介紹可以參見Linux的大頁表文件系統（hugetlbfs）特性。DPDK則利用大頁技術，所有的內存都是從HugePage里分配，實現對內存池(mempool)的管理，并預先分配好同樣大小的mbuf，供每一個數據包使用。2.3輪詢技術傳統網卡的報文接收/發送過程中，網卡硬件收到網絡報文，或發送完網絡報文后，需要發送中斷到CPU，通知應用軟件有網絡報文需要處理。在x86處理器上，一次中斷處理需要將處理器的狀態寄存器保存到堆棧，并運行中斷服務程序，最后再將保存的狀態寄存器信息從堆棧中恢復。整個過程需要至少300個處理器時鐘周期。對于高性能網絡處理應用，頻繁的中斷處理開銷極大降低了網絡應用程序的性能。為了減少中斷處理開銷，DPDK使用了輪詢技術來處理網絡報文。網卡收到報文后，直接將報文保存到處理器cache中（有DDIO（DirectDataI/O）技術的情況下），或者保存到內存中（沒有DDIO技術的情況下），并設置報文到達的標志位。應用軟件則周期性地輪詢報文到達的標志位，檢測是否有新報文需要處理。整個過程中完全沒有中斷處理過程，因此應用程序的網絡報文處理能力得以極大提升。2.4CPU親和技術現代操作系統都是基于分時調用方式來實現任務調度，多個進程或線程在多核處理器的某一個核上不斷地交替執行。每次切換過程，都需要將處理器的狀態寄存器保存在堆棧中，并恢復當前進程的狀態信息，這對系統其實是一種處理開銷。將一個線程固定一個核上運行，可以消除切換帶來的額外開銷。另外將進程或者線程遷移到多核處理器的其它核上進行運行時，處理器緩存中的數據也需要進行清除，導致處理器緩存的利用效果降低。CPU親和技術，就是將某個進程或者線程綁定到特定的一個或者多個核上執行，而不被遷移到其它核上運行，這樣就保證了專用程序的性能。DPDK使用了Linuxpthread庫，在系統中把相應的線程和CPU進行親和性綁定,然后相應的線程盡可能使用獨立的資源進行相關的數據處理。2.5DPDK性能影響因素硬件結構的影響DPDK具有廣泛的平臺適應性，可以運行在整個x86平臺，從主流服務器平臺（從高性能或者高能效產品系列），到桌面或者嵌入式平臺，也可以運行于基于Power或者其他架構的運算平臺。圖展示了一個通用雙路服務器的內部架構，它包含了2個中央處理器，2個分離的內存控制單元來連接系統內存，芯片組會擴展出大量高速的PCIe2.0/3.0接口，用于連接外設，如10Gbps或者25Gbps網卡外設。OS版本及其內核的影響不同的LinuxOS發行版使用的Linux內核版本不一樣，配置的LinuxOS服務也不一樣。這些差異都會導致應用程序在網絡報文處理能力上有所差別。由于Linux內核還在不斷演進，Linux的發行版也數量眾多，本文無法提供最佳Linux內核版本和配置，而只能給出部分參考建議，如：關閉部分OS服務。在后續章節，我們選取了目前比較流行的Linux發行版進行了測試，并給出測試結果。從測試結果中顯示，同樣的硬件配置環境下，不同的Linux發行版在小包的處理能力上存在差異。關閉OS部分服務在10G端口上64Byte報文的線速到達率為14.88Mpps，如果實現零丟包的線速處理，每個報文的平均處理速度應該小于1/14.48Mpps=67us，DPDK應用的網卡收發包隊列長度缺省配置為128，網卡隊列填充滿的時間是128*67=8579us。也就是說，DPDK的業務進程，如果被操作系統中斷超過8579us，就會導致網卡收發報的隊列被充滿，無法接收新的報文，從而導致丟包。而操作系統的中斷服務程序、后臺服務程序、以及任務調度程序都會導致DPDK的應用程序被打斷。在NFV應用場景下，Host機器上和Guest機器上都運行著操作系統，由此帶來了兩級的操作任務調度。DPDK應用程序（NFV中的VNF）均運行在虛擬機上，操作系統帶來的影響會更加明顯。為了實現DPDK應用程序的零丟包，需要對操作系統進行適當的配置，減少操作系統的對DPDK應用程序的干擾。操作系統配置的總體思路是：將運行DPDK應用運行的處理器核進行隔離，減少干擾；停用不需要的后臺服務程序。將不需要的中斷，轉移到其它處理器核上處理；對于不能轉移的中斷，減少中斷的次數。OS調整示例下面以CentOS7為例，說明具體的調整方法。絕大部分的操作需要同時在Host操作系統和Guest操作系統同時應用。1)對DPDK應用使用處理器核進行隔離修改Linux的OS的GRUB參數，設置isolCPUs=16-23,40-472)打開運行有DPDK進程的處理器核上的nohz_full。nohz_full可以減少內核的周期性時鐘中斷的次數。修改Linux的OS的GRUB參數，設置nohz_full=16-23,40-473)關閉NMI監控功能，減少NMI中斷對DPDK任務的干擾。修改Linux的OS的GRUB參數，設置nmi_watchdog=04)關閉SELinux功能修改Linux的OS的GRUB參數，設置selinux=05)關閉處理器的P狀態調整和softlockup功能。將處理器鎖定在固定的頻率運行，減少處理器在不同的P狀態切換帶來的處理時延。修改Linux的OS的GRUB參數，設置intel_pstate=disablenosoftlockup6)關閉圖形顯示，減少GUI應用的干擾調用命令systemctlset-defaultmulti-user.target7)關閉操作系統的中斷調度程序調用命令systemctldisableirqbalance.service8)關閉操作系統的審計服務調用命令systemctldisableauditd.service9)關閉藍牙服務調用命令systemctldisablebluetooth.service10)關閉KVM的內存頁合并服務調用命令systemctldisableksm.service調用命令systemctldisableksmtuned.service11)對于KVM虛擬的vCPU和物理CPU進行綁定使用QEMUmonitor獲取vCPU對應的線程號，使用taskset命令進行綁定。OVS性能問題OVS作為NFV的一個重要組成模塊，會運行在絕大多數的服務器節點上，提供虛擬機和虛擬機之間，以及虛擬網絡和物理網絡間的互連接口，其性能至關重要。OVS2.4開始正式支持DPDK加速，相比傳統基于Linux內核的OVS版本，轉發性能提高了數倍，為VNF在通用x86服務器上部署提供了有力支持。OVS缺省會為每一個NUMA節點創建一個pmd線程，該pmd線程以輪詢方式處理屬于其NUMA節點上的所有DPDK接口。為了高性能，需要利用前面提到的CPU親和技術，把pmd線程綁定在一個固定的CPUcore上處理。此外，為了增加擴展性，OVS2.4也支持網卡多隊列以及多pmd線程數，這些參數均可動態配置，但具體配置應根據具體需求來決定。內存管理如前所述，DPDK考慮了NUMA以及多內存通道的訪問效率，會在系統運行前要求配置Linux的HugePage，初始化時申請其內存池，用于DPDK運行的主要內存資源。Linux大頁機制利用了處理器核上的的TLB的HugePage表項，這可以減少內存地址轉換的開銷。內存多通道的使用現代的內存控制器都支持內存多通道，比如Intel的E5-2600V3系列處理器，能支持4個通道，可以同時讀和取數據。依賴于內存控制器及其配置，內存分布在這些通道上。每一個通道都有一個帶寬上限，如果所有的內存訪問都只發生在第一個通道上，這將成為一個潛在的性能瓶頸。因此，DPDK的mempool庫缺省是把所有的對象分配在不同的內存通道上，保證了在系統極端情況下需要大量內存訪問時，盡可能地將內存訪問任務均勻平滑。內存拷貝很多libc的API都沒有考慮性能，因此，不要在高性能數據平面上用libc提供的API，比如，memcpy()或strcpy()。雖然DPDK也用了很多libc的API，但均只是在軟件配置方面用于方便程序移植和開發。DPDK提供了一個優化版本的rte_memcpy()API，它充分利用了Intel的SIMD指令集，也考慮了數據的對齊特性和cache操作友好性。內存分配在某些情況下，應用程序使用libc提供的動態內存分配機制是必要的，如malloc()函數，它是一種靈活的內存分配和釋放方式。但是，因為管理零散的堆內存代價昂貴，并且這種內存分配器對于并行的請求分配性能不佳，所以不建議在數據平面處理上使用類似malloc()的函數進行內存分配。在有動態分配的需求下，建議使用DPDK提供的rte_malloc()API，該API可以在后臺保證從本NUMA節點內存的HugePage里分配內存，并實現cacheline對齊以及無鎖方式訪問對象等功能。NUMA考慮NUMA（NonUniformMemoryAccessArchitecture）與SMP（SymmetricMultiProcessing）是兩種典型的處理器對內存的訪問架構。隨著處理器進入多核時代，對于內存吞吐量和延遲性能有了更高的要求，NUMA架構已廣泛用于最新的英特爾處理器中，為每個處理器提供分離的內存和內存控制器，以避免SMP架構中多個處理器同時訪問同一個存儲器產生的性能損失。在雙路服務器平臺上，NUMA架構存在本地內存與遠端內存的差異。本地和遠端是個相對概念，是指內存相對于具體運行程序的處理器而言，如圖所示。在NUMA體系架構中，CPU進行內存訪問時，本地內存的要比訪問遠端內存更快。因為訪問遠端內存時，需要跨越QPI總線，在應用軟件設計中應該盡量避免。在高速報文處理中，這個訪問延遲會大幅降低系統性能。尤其是傳統嵌入式軟件向服務器平臺遷移時，需要特別關注。DPDK提供了一套在指定NUMA節點上創建memzone、ring,rte_malloc以及mempool的API，可以避免遠端內存訪問這類問題。在一個NUMA節點端，對于內存變量進行讀取不會存在性能問題，因為該變量會在CPUcache里。但對于跨NUMA架構的內存變量讀取，會存在性能問題，可以采取復制一份該變量的副本到本地節點（內存）的方法來提高性能。CPU核間無鎖通信如果想建立一個基于消息傳遞的核間通信機制，可以使用DPDKringAPI，它是一個無鎖的ring實現。該ring機制支持批量和突發訪問，即使同時讀取幾個對象，也只需要一個昂貴的原子操作，批量訪問可以極大地改善性能。設置正確的目標CPU類型DPDK支持CPU微架構級別的優化，可以通過修改DPDK配置文件中的CONFIG_RTE_MACHINE參數來定義。優化的程度根據隨編譯器的能力而不同，通常建議采用最新的編譯器進行編譯。如果編譯器的版本不支持該款CPU的特性，比如IntelAVX指令，那么它在編譯時只會選用自己支持的指令集，這可能導致編譯后生成的DPDK應用的性能下降。三、Hugepage配置DPDK中，如果有多個核可能需要同時訪問一個網卡，那DPDK中會為每個核準備一個單獨的接收隊列/發送隊列，這樣避免了競爭，也避免了cache一致性問題。一般的常規頁大小為4K字節，使用大頁時頁大小設置為2M或1G字節。修改方式如下：Bashrc文件內添加：非NUMA系統Echo1024>/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages預留了1024個2M大頁，即2GB內存。NUMA系統Echo1024>/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages

Echo1024>/sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages上述命令為每個節點各預留了1024個2M大頁，即4GB內存。/etc/fstab內添加掛載2M大頁：Nodev/mnt/hugehugetlbfsdefaults00

掛載1G大頁：Nodev/mnt/huge_1GBhugetlbfspagesize=1GB003.1多線程配置DPDK線程基于pthread接口創建，屬于搶占式線程模型，受內核調度支配。通過在多核設備上創建多個線程，每個線程綁定到單獨的核上，減少線程調度的開銷，以提高性能。控制線程一般綁定到MASTER核上，接受用戶配置，并傳遞配置參數給數據線程等；數據線程分布在不同核上處理數據包。DPDK中初始化及執行任務分發示例如下圖所示：lcore初始化及執行任務分發，上圖中一共使用了三個cpu核，mastercore負責進行任務初始化和分發，兩個lcore執行任務。3.2轉發模型DPDK轉發框架分為runtocompletion模型和pipeline模型，對比圖如下：DPDK轉發模型對比，DPDKruntocompletion模型中每個報文的生命周期只能在一個線程中出現，每個物理核都負責處理整個報文的生命周期從RX到TX。DPDKpipeline模型中不同的工作交給不同的模塊，每一個模塊只單獨處理特定的事務，各模塊之間有輸入輸出，通過這些輸入輸出連接起來，完成復雜的網絡功能.3.3內存管理DPDK將內存封裝在Mbuf結構體內，Mbuf主要用來封裝網絡幀緩存，所有的應用使用Mbuf結構來傳輸網絡幀。對網絡幀封裝和處理時，將網絡幀元數據和幀本身存放在固定大小的同一段緩存中，網絡幀元數據的一部分內容由DPDK的網卡驅動寫入，結構如下圖：單幀Mbuf結構headroom用來存儲和系統中其他實體交互的信息，如控制信息、幀內容、事件等。Headroom長度由RTE_PKTMBUF_HEADROOM定義，默認為128.Rte_mbuf結構對象存放在內存池中，內存池使用環形緩存區來保存空閑對象，邏輯結構如下圖所示：內存池雙環形緩存區結構,當一個網絡幀被網卡接收時，DPDK網卡驅動將其存儲在一個高效的環形緩沖區中，同時Mbuf的環形緩存區中創建了一個Mbuf對象。Mbuf對象被創建好后，網卡驅動根據分析出的幀信息將其初始化，并將其和實際幀對象邏輯相連，對網絡幀的分析處理都集中在Mbuf，僅在必要的時候訪問實際網絡幀。四、性能優化4.1收發包流程概述DPDK中普遍采用純輪詢模式進行數據包收發，所有的收發包有關的中斷在物理端口初始化的時候都會關閉。物理端口上的每一個收包隊列，都會有一個對應的由收包描述符組成的軟件隊列來進行硬件和軟件的交互。DPDK驅動程序負責初始化好每一個收包描述符，其中包含把包緩沖內存塊的物理地址填充到收包描述符對應的位置，并把對應的收包成功標志復位，通知網卡硬件把收到的包進行填充。網卡硬件將收到的包一一填充到對應的收包描述符表示的緩沖內存塊中，將必要信息填充到收包描述符內，標記好收包成功標志。若一個緩沖區內存塊大小不夠存放一個完整數據包時，可能需要多個收包描述符來處理一個包。針對每一個收包隊列，DPDK都會有一個對應的軟件線程負責輪詢其中的收包描述符收包成功的標志位。當發現一個收包描述符的收包成功標志被硬件置位了，意味著有包進入網卡并且已經存儲到描述符對應的緩沖區內存塊中。驅動程序將解析相應的收包描述符，填充對應緩沖內存塊頭部，將收包緩沖內存塊存放到收包函數提供的數組中，同時分配好一個新的緩沖內存塊給這個描述符，以便下一次收包。針對每一個發包隊列，DPDK都有一個對應的軟件線程負責設置需要發送出去的包，DPDK驅動程序負責提取發包緩沖內存塊的有效信息，根據內存緩存塊中包的內容來負責初始化好每一個發包描述符，驅動程序將每個包翻譯為一個或者多個發包描述符內能夠理解的內容，寫入發包描述符。當驅動程序設置好相應的發包描述符，硬件就開始依據發包描述符內容來發包，驅動程序通過獲取發包描述符內的RS發送狀態位來決定發包是否結束以及對發包描述符和內存緩沖塊進行回收。發包輪詢就是輪詢發包結束的硬件標志位，DPDK驅動程序會在發包線程內不斷查詢發包是否結束，網卡根據RS以寫回方式通知發包結束。4.2Burst收發包Burst為一次完成多個數據包的收發，通過把收發包復雜的處理過程進行分解，打散成不同的相對較小的處理階段，把相鄰數據訪問、相似的數據運算集中處理，盡可能減少對內存或者低一級的處理器緩存的訪問次數。網卡收發包描述符一般為16字節或32字節，處理器緩存基本單位為64字節，可以存放2個或4個描述符，處理器預期機制會每次存取相鄰多個緩存，若一次處理4個緩存單元，則可以更新16個描述符，Burst就可以設置為16.目前常用的Burst為32。4.3平臺優化配置硬件：PCIeGen3x8,x16。網卡多隊列收發包，支持收包RSS時分發進多個隊列。軟件：關閉CPU以及設備的省電模式；讓內存運行在所支持的最高頻率上；內核初始化時設置好大頁；增加內核啟動參數，預先指定DPDK使用的邏輯核，不被操作系統調度；DPDK參數配置：收包隊列長度，即每個收包隊列分配的收包描述符個數，反映了在軟件驅動程序讀取所收到包之前最大的緩存包的能力。太長占用資源，太短容易丟包，默認長度為128.發包隊列長度，即每個發包隊列分配的發包描述符個數，默認長度為512.收包隊列可釋放描述符數量閾值，DPDK驅動程序并沒有每次收包都更新收包隊列尾部索引寄存器，而是在可釋放的收包描述符數量達到一個閾值時更新，設置合理，可以減少沒有必要的過多收包隊列尾部索引寄存器的訪問。默認值為32.發包隊列可釋放描述符數量閾值，通過將回寫標記設置在一定間隔的發包描述符上，減少不必要的回寫次數，改善性能，默認為32.發包描述符釋放閾值，當用來重新配置的發包描述符數量少于閾值時，才會啟動描述符和Mbuf釋放動作，設置太大釋放頻繁，影響性能，設置太小可用描述符少，容易丟包，默認值為32。4.4多隊列配置DPDK中，通過將網卡的某個接收隊列分配給某個核，從該隊列中收到的所有報文都應當在該指定的核上處理結束，不同的核操作不同的隊列。目前可以通過RSS(接收方擴展)把數據包分配到不同的隊列中，該機制根據關鍵字通過哈希函數計算出哈希值，再有哈希值確定隊列。不同的數據包類型具有不同的關鍵字，例如IPv4UDP四元組（源IP地址、目的IP地址、源端口號、目的端口號）。另一種是FlowDirector技術，根據包的字段精確匹配，查找FlowDirector表項，將其分配到某個特定隊列。DPDK中可以采用RSS來負載均衡，將報文發到多個核上，同時使用FlowDirector將控制報文分配到指定的隊列上，使用單獨的核來處理，如下圖所示：五、DPDK學習路線這里給大家推薦零聲教育全網獨家的【dpdk-網絡協議棧-vpp-OVS-DDos-虛擬化技術】課程體系，通過32個項目案例，2W+行手寫代碼，全面解析4個dpdk技術方向：5.1DPDK網絡專欄（1）dpdk基礎知識1.多隊列網卡，vmxnet/e10002.igb_uio與vfio模塊3.kni模塊4.hugepage的理解5.零拷貝6.dpdk與netmap區別7.dpdk的工作環境（2）網絡協議棧1.sh靜態arp表設置3.dpdk-icmp4.udp協議格式分析5.udp協議sendto,recvfrom實現6.dpdk-ip7.dpdk-tcp8.tcp協議棧bind,listen,accept實現9.tcp協議棧recv,send,close的實現10.tcp三次握手實現11.tcp四次揮手實現12.tcpacknum與seqnum的確認機制實現13.tcp的并發連接設計14.epoll并發的實現15.tcp協議棧與epoll之間的回調實現（3）dpdk組件項目1.dpdk-ac2.dpdk-kni3./dev/kni的原理分析4.kni_dev的流程5.kni的t緩沖區，rx緩沖區6.kni的用戶空間與內核空間映射7.mbuf如何轉化為kernel的sk_buff8.dpdk-timer9.bpftrace的使用10.dpdk-bpf源碼流程（4）dpdk經典項目1.dpdk-dns2.dpdk-gateway3.dpdk-ddos熵計算源碼4.ddosattach檢測精確度調試5.ddosattach測試T具hping36.布谷鳥hash原理與使用5.2儲存技術專欄（1）高效磁盤io讀寫spdk(C)1.存儲框架spdk,為技術棧打開扇存儲的大門2.spdk運行環境與vhost3.NVMe與PCl的關系4.手把手實現spdk_server5.nvme與pcie以及手寫nvme讀寫操作6.bdev與blob之間的關系7.實現blob異步讀寫8.blobstore的讀寫操作實現與rpc的關系9.fio性能測試性能對比libaio,io_uring,psync10.fioplugin工作流程11.fioplugin開發（2）spdk文件系統的實現1.文件系統功能拆解2.spdk_env_init與spdk_appinit的差別3.spdk__thread_poll實現rpc回調4.fs_operations結構體定義5.file_operations結構體定義6.dir_operations結構體定義7.syscall的hook實現8.io內存管理9.基數樹對文件系統內存管理10.spdk_blob的open,read,write,close11.測試用例與調試入口函數（3）spdkkv存儲的實現1.KV存儲拆解Set,Get,Mod,Del2.app/.a庫/so庫對于kv存儲的選擇3.bdev與blob對于kv存儲的選擇4.kvservice啟動blob資源操作5.kvservice關閉blob資源回收6.kvservice接口set,get,modify,delete7.kv遍歷與查找實現8.page存儲chunk的管理9.pagechunk的get與put10.page單查找與多頁查找11.btree,artree,hashmap,radixtree,rbtree之間的選擇12.slab的實現13.slab分配slot與釋放slot14.為kv加上conf文件15.測試用例與性能測試5.3安全與網關開發專欄（1）可擴展的矢量數據包處理框架vpp(c/c+