01 技術原理與架構

由于采用軟件轉發和軟件交換技術，單服務器內部的轉發能力是 NFV 系統的主要性能瓶頸。在各類高速轉發的 NFV 應用中，數據報文從網卡中接收，再傳送到虛擬化的用戶態應用程序（VNF）處理，整個過程要經歷 CPU 中斷處理、虛擬化 I/O 與地址映射轉換、虛擬交換層、網絡協議棧、內核上下文切換、內存拷貝等多個費時的 CPU 操作和 I/O 處理環節。

業內通常采用消除海量中斷、旁路內核協議棧、減少內存拷貝、CPU 多核任務分擔、Intel VT 等技術來綜合提升服務器數據平面的報文處理性能，普通用戶較難掌握。業界迫切需要一種綜合的性能優化方案，同時提供良好的用戶開發和商業集成環境，DPDK 加速技術方案成為其中的典型代表。

DPDK 是一個開源的數據平面開發工具集，提供了一個用戶空間下的高效數據包處理庫函數，它通過環境抽象層旁路內核協議棧、輪詢模式的報文無中斷收發、優化內存/緩沖區/隊列管理、基于網卡多隊列和流識別的負載均衡等多項技術，實現了在 x86 處理器架構下的高性能報文轉發能力，用戶可以在 Linux 用戶態空間開發各類高速轉發應用，也適合與各類商業化的數據平面加速解決方案進行集成。

英特爾在 2010 年啟動了對 DPDK 技術的開源化進程，于當年 9 月通過 BSD 開源許可協議正式發布源代碼軟件包，并于 2014 年 4 月在 www.dpdk.org 上正式成立了獨立的開源社區平臺，為開發者提供支持。開源社區的參與者們大幅推進了 DPDK 的技術創新和快速演進，而今它已發展成為 SDN 和 NFV 的一項關鍵技術。

02 軟件架構

DPDK 的組成架構如圖所示，相關技術原理概述如下：

在最底部的內核態（Linux Kernel）DPDK 有兩個模塊：KNI 與 IGB_UIO。其中，KNI 提供給用戶一個使用 Linux 內核態的協議棧，以及傳統的 Linux 網絡工具（如ethtool， ifconfig）。IGB_UIO（igb_uio.ko 和 kni.ko. IGB_UIO）則借助了 UIO 技術，在初始化過程中將網卡硬件寄存器映射到用戶態。

如圖，DPDK 的上層用戶態由很多庫組成，主要包括核心部件庫（Core Libraries）、平臺相關模塊（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）。

03 大頁技術

處理器的內存管理包含兩個概念：物理內存和虛擬內存。Linux 操作系統里面整個物理內存按幀（frames）來進行管理，虛擬內存按照頁（page）來進行管理。內存管理單元（MMU）完成從虛擬內存地址到物理內存地址的轉換。內存管理單元進行地址轉換需要的信息保存在一個叫頁表（page table）的數據結構里面，頁表查找是一種極其耗時的操作。

x86 處理器硬件在缺省配置下，頁的大小是 4K，但也可以支持更大的頁表尺寸，例如2M 或 1G 的頁表。使用了大頁表功能后，一個 TLB 表項可以指向更大的內存區域，這樣可以大幅減少 TLB miss 的發生。早期的 Linux 并沒有利用 x86 硬件提供的大頁表功能，僅在 Linux內核 2.6.33 以后的版本，應用軟件才可以使用大頁表功能，具體的介紹可以參見 Linux 的大頁表文件系統（hugetlbfs）特性。

DPDK 則利用大頁技術，所有的內存都是從 HugePage 里分配，實現對內存池（mempool）的管理，并預先分配好同樣大小的 mbuf，供每一個數據包使用。

04 輪詢技術

為了減少中斷處理開銷，DPDK 使用了輪詢技術來處理網絡報文。網卡收到報文后，直接將報文保存到處理器 cache 中（有 DDIO（Direct Data I/O）技術的情況下），或者保存到內存中（沒有 DDIO 技術的情況下），并設置報文到達的標志位。應用軟件則周期性地輪詢報文到達的標志位，檢測是否有新報文需要處理。整個過程中完全沒有中斷處理過程，因此應用程序的網絡報文處理能力得以極大提升。

05 GPU親和技術

現代操作系統都是基于分時調用方式來實現任務調度，多個進程或線程在多核處理器的某一個核上不斷地交替執行。每次切換過程，都需要將處理器的狀態寄存器保存在堆棧中，并恢復當前進程的狀態信息，這對系統其實是一種處理開銷。將一個線程固定一個核上運行，可以消除切換帶來的額外開銷。另外將進程或者線程遷移到多核處理器的其它核上進行運行時，處理器緩存中的數據也需要進行清除，導致處理器緩存的利用效果降低。

CPU 親和技術，就是將某個進程或者線程綁定到特定的一個或者多個核上執行，而不被遷移到其它核上運行，這樣就保證了專用程序的性能。

DPDK 使用了 Linux pthread 庫，在系統中把相應的線程和 CPU 進行親和性綁定， 然后相應的線程盡可能使用獨立的資源進行相關的數據處理。

基于 DPDK 進行應用開發和環境配置時，應用程序性能的影響因素以及相應的優化調整方法。這些因素并非必然劣化性能，可能因硬件能力、OS 版本、各類軟硬環境參數配置等的差異產生較大波動，或者存在較大的不穩定性，相關的調優方法需要用戶結合自身的VNF應用部署在實踐中不斷完善。

1、硬件結構的影響

DPDK 具有廣泛的平臺適應性，可以運行在整個 x86 平臺，從主流服務器平臺（從高性能或者高能效產品系列），到桌面或者嵌入式平臺，也可以運行于基于 Power 或者其他架構的運算平臺。圖展示了一個通用雙路服務器的內部架構，它包含了 2 個中央處理器，2個分離的內存控制單元來連接系統內存，芯片組會擴展出大量高速的 PCIe 2.0/3.0 接口，用于連接外設，如 10Gbps 或者 25Gbps 網卡外設。

2、OS 版本及其內核的影響

不同的 Linux OS 發行版使用的 Linux 內核版本不一樣，配置的 Linux OS服務也不一樣。這些差異都會導致應用程序在網絡報文處理能力上有所差別。

由于 Linux 內核還在不斷演進，Linux 的發行版也數量眾多，本文無法提供最佳 Linux內核版本和配置，而只能給出部分參考建議，如：關閉部分 OS 服務。在后續章節，我們選取了目前比較流行的 Linux 發行版進行了測試，并給出測試結果。從測試結果中顯示，同樣的硬件配置環境下，不同的 Linux 發行版在小包的處理能力上存在差異。

2.1 關閉 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 應用運行的處理器核進行隔離，減少干擾；

停用不需要的后臺服務程序。將不需要的中斷，轉移到其它處理器核上處理；

對于不能轉移的中斷，減少中斷的次數。

2.2 OS 調整示例

下面以 CentOS 7 為例，說明具體的調整方法。絕大部分的操作需要同時在 Host 操作系統和 Guest 操作系統同時應用。

1） 對 DPDK 應用使用處理器核進行隔離。

修改 Linux 的 OS 的 GRUB 參數，設置 isolCPUs=16-23，40-47；2） 打開運行有 DPDK 進程的處理器核上的 nohz_full。nohz_full 可以減少內核的周期性時鐘中斷的次數。修改 Linux 的 OS 的 GRUB 參數，設置 nohz_full=16-23，40-47；3） 關閉 NMI 監控功能，減少 NMI 中斷對 DPDK 任務的干擾。修改 Linux 的 OS 的 GRUB 參數，設置 nmi_watchdog=0；4） 關閉 SELinux 功能修改 Linux 的 OS 的 GRUB 參數，設置 selinux=0；5） 關閉處理器的 P 狀態調整和 softlockup 功能。將處理器鎖定在固定的頻率運行，減少處理器在不同的 P 狀態切換帶來的處理時延。修改 Linux 的 OS 的 GRUB 參數，設置 intel_pstate=disable nosoftlockup；6） 關閉圖形顯示，減少 GUI 應用的干擾。調用命令 systemctl set-default multi-user.target；7） 關閉操作系統的中斷調度程序。調用命令 systemctl disable irqbalance.service；8） 關閉操作系統的審計服務。調用命令 systemctl disable auditd.service；9） 關閉藍牙服務。調用命令 systemctl disable bluetooth.service；10） 關閉 KVM 的內存頁合并服務。調用命令 systemctl disable ksm.service；調用命令 systemctl disable ksmtuned.service；

11） 對于 KVM 虛擬的 vCPU 和物理 CPU 進行綁定。使用 QEMU monitor 獲取 vCPU 對應的線程號，使用 taskset 命令進行綁定。

2.3 OVS 性能問題

OVS 作為 NFV 的一個重要組成模塊，會運行在絕大多數的服務器節點上，提供虛擬機和虛擬機之間，以及虛擬網絡和物理網絡間的互連接口，其性能至關重要。OVS 2.4 開始正式支持 DPDK 加速，相比傳統基于 Linux 內核的 OVS 版本，轉發性能提高了數倍，為 VNF 在通用 x86 服務器上部署提供了有力支持。

OVS 缺省會為每一個 NUMA 節點創建一個 pmd 線程，該 pmd 線程以輪詢方式處理屬于其NUMA 節點上的所有 DPDK 接口。為了高性能，需要利用前面提到的 CPU 親和技術，把 pmd 線程綁定在一個固定的 CPU core 上處理。此外，為了增加擴展性，OVS 2.4 也支持網卡多隊列以及多 pmd 線程數，這些參數均可動態配置，但具體配置應根據具體需求來決定。

3、內存管理

如前所述，DPDK 考慮了 NUMA 以及多內存通道的訪問效率，會在系統運行前要求配置Linux 的 HugePage，初始化時申請其內存池，用于 DPDK 運行的主要內存資源。Linux 大頁機制利用了處理器核上的的 TLB 的 HugePage 表項，這可以減少內存地址轉換的開銷。

3.1 內存多通道的使用

現代的內存控制器都支持內存多通道，比如 Intel 的 E5-2600V3 系列處理器，能支持 4個通道，可以同時讀和取數據。依賴于內存控制器及其配置，內存分布在這些通道上。每一個通道都有一個帶寬上限，如果所有的內存訪問都只發生在第一個通道上，這將成為一個潛在的性能瓶頸。

因此，DPDK 的 mempool 庫缺省是把所有的對象分配在不同的內存通道上，保證了在系統極端情況下需要大量內存訪問時，盡可能地將內存訪問任務均勻平滑。

3.2 內存拷貝

很多 libc 的 API 都沒有考慮性能，因此，不要在高性能數據平面上用 libc 提供的 API，比如，memcpy（）或 strcpy（）。雖然 DPDK 也用了很多 libc 的 API，但均只是在軟件配置方面用于方便程序移植和開發。

DPDK 提供了一個優化版本的 rte_memcpy（） API，它充分利用了 Intel 的 SIMD 指令集，也考慮了數據的對齊特性和 cache 操作友好性。

3.3 內存分配

在某些情況下，應用程序使用 libc 提供的動態內存分配機制是必要的，如 malloc（）函數，它是一種靈活的內存分配和釋放方式。但是，因為管理零散的堆內存代價昂貴，并且這種內存分配器對于并行的請求分配性能不佳，所以不建議在數據平面處理上使用類似malloc（）的函數進行內存分配。

在有動態分配的需求下，建議使用 DPDK 提供的 rte_malloc（） API，該 API 可以在后臺保證從本 NUMA 節點內存的 HugePage 里分配內存，并實現 cache line 對齊以及無鎖方式訪問對象等功能。

3.4 NUMA 考慮

NUMA（Non Uniform Memory Access Architecture）與 SMP（Symmetric Multi Processing）是兩種典型的處理器對內存的訪問架構。隨著處理器進入多核時代，對于內存吞吐量和延遲性能有了更高的要求，NUMA 架構已廣泛用于最新的英特爾處理器中，為每個處理器提供分離的內存和內存控制器，以避免 SMP 架構中多個處理器同時訪問同一個存儲器產生的性能損失。

在雙路服務器平臺上，NUMA 架構存在本地內存與遠端內存的差異。本地和遠端是個相對概念，是指內存相對于具體運行程序的處理器而言，如圖所示。

在 NUMA 體系架構中，CPU 進行內存訪問時，本地內存的要比訪問遠端內存更快。因為訪問遠端內存時，需要跨越 QPI 總線，在應用軟件設計中應該盡量避免。在高速報文處理中，這個訪問延遲會大幅降低系統性能。尤其是傳統嵌入式軟件向服務器平臺遷移時，需要特別關注。

DPDK 提供了一套在指定 NUMA 節點上創建 memzone、ring， rte_malloc 以及 mempool 的API，可以避免遠端內存訪問這類問題。在一個 NUMA 節點端，對于內存變量進行讀取不會存在性能問題，因為該變量會在 CPU cache 里。但對于跨 NUMA 架構的內存變量讀取，會存在性能問題，可以采取復制一份該變量的副本到本地節點（內存）的方法來提高性能。

4、CPU 核間無鎖通信

如果想建立一個基于消息傳遞的核間通信機制，可以使用 DPDK ring API，它是一個無鎖的 ring 實現。該 ring 機制支持批量和突發訪問，即使同時讀取幾個對象，也只需要一個昂貴的原子操作，批量訪問可以極大地改善性能。

5、設置正確的目標 CPU 類型

DPDK支持CPU微架構級別的優化，可以通過修改DPDK配置文件中的CONFIG_RTE_MACHINE參數來定義。優化的程度根據隨編譯器的能力而不同，通常建議采用最新的編譯器進行編譯。

如果編譯器的版本不支持該款 CPU 的特性，比如 Intel AVX 指令，那么它在編譯時只會選用自己支持的指令集，這可能導致編譯 后生成的 DPDK 應用的性能下降。