本文將介紹可選的幾種不同配置選項，并為讀者日后的選擇提供建議。

環境抽象層（EAL）參數

環境抽象層（EAL）是DPDK的核心。它是DPDK的一個庫。顧名思義，它負責抽象出環境（硬件、操作系統等）并為軟件提供統一的接口。EAL要處理很多東西，所以也不難理解為何它會是DPDK中最復雜的一個部分。由EAL負責處理的包括：

· 管理CPU核心和非統一內存訪問（NUMA）節點

· 將硬件設備的寄存器映射到內存中，使它們可受DPDK輪詢模式驅動程序（PMDs）驅動

· 管理硬件和軟件中斷

· 抽象出平臺差異，如字節序、緩存行大小等

· 管理內存和多進程同步

· 提供與原子、內存屏障和其他同步原語共通的獨立于平臺和操作系統的方法

· 加載和枚舉硬件總線，設備和PMD

以上只羅列了EAL的部分功能，但這足以體現它對于DPDK的重要性。因此，DPDK中大量配置與EAL有關也不足為奇。目前，可以通過（直接或間接地）為DPDK初始化例程指定命令行參數對EAL進行配置。DPDK應用命令行通常如下所示：

./app --

某些使用DPDK的應用（如OvS-DPDK）可能會對用戶隱藏此步驟，因此可能不需要明確指定EAL命令行參數，但盡管如此此步驟還是會在后臺進行。

IO虛擬地址（IOVA）模式

DPDK是一個用戶態應用框架，使用DPDK的軟件可以像其他軟件一樣使用常規虛擬地址。但除此之外，DPDK還提供了用戶態PMD和一組API，以實現完全以用戶態執行IO操作。本系列的前一篇也已經提到過，硬件不能讀取用戶空間虛擬地址;它使用的是IO地址——物理地址（PA）或IO虛擬地址（IOVA）。

DPDK API對物理和IO虛擬地址不作區分，即使不是由IO內存管理單元（IOMMU）提供VA部分，也都以IOVA來代表兩種地址。但DPDK卻會區分物理地址用作IOVA的情況，和IOVA與用戶空間虛擬地址匹配的情況。它們在DPDK API中被稱為IOVA模式，可分為兩種：作為PA的IOVA模式，和作為VA的IOVA模式。

作為物理地址（PA）的IOVA模式

作為PA的IOVA模式下，分配到整個DPDK存儲區的IOVA地址都是實際的物理地址，而虛擬內存的分配與物理內存的分配相匹配。該模式的一大優點就是它很簡單：它適用于所有硬件（也就是說，不需要IOMMU），并且它適用于內核空間（將真實物理地址轉換為內核空間地址的開銷是微不足道的）。實際上，這就是DPDK長期以來的運作方式，在很多方面它都被認為是默認的選項。

然而，作為PA的IOVA模式也存在一些缺點。其中一個就是它需要根用戶特權——如果無法訪問系統的頁面映射，DPDK就無法獲取內存區域的真實物理地址。因此，如果系統中沒有root權限，就無法以該模式運行。

圖1.作為PA的IOVA模式。

作為PA的IOVA模式還有另外一個值得一提的限制——虛擬內存分配要遵循物理內存分配。這意味著如果物理內存空間被分段（被分成許多小段而不是幾個大段）時，虛擬內存空間也要遵循同樣的分段。極端情況下，分段可能過于嚴重，導致被分割出來物理上連續的片段數量過多，耗盡DPDK用于存儲這些片段相關信息的內部數據結構，就會讓DPDK初始化失敗。

圖2.作為PA的IOVA模式下PA分段示例。

應對這些問題，DPDK社區提出了解決方法。舉例來說，一種減少分段影響的方式是使用更大的分頁——問題雖然沒被解決，但是單獨的1千兆字節（GB）段比獨立的2兆字節（MB）段能大幅度減小分段的數量。另外一種廣泛使用的解決方式則是在啟動時引導系統并保留大頁，而不是在運行時。但上述的解決方法都不能根本地解決問題，而且整個DPDK社區都習慣了要去解決這些問題，每個DPDK用戶（有意或無意）在使用時都會采取相同的思維模式——“我需要X MB內存，但以防萬一，我要保留X + Y MB！”

作為虛擬地址（VA）的IOVA模式

相比之下，作為VA的IOVA模式不需遵循底層物理內存的分布。而是重新分配物理內存，與虛擬內存的分配匹配。DPDK EAL依靠內核基礎設施來實現這一點。內核基礎設施又反過來使用IOMMU重新映射物理內存。

圖3.作為VA的IOVA模式。

這種方式的優點顯而易見：作為VA的IOVA模式下，所有內存都是VA-和IOVA-連續的。這意味著所有需要大量IOVA連續內存的內存分配更有可能成功，因為對硬件來說，即使底層物理內存可能不存在，內存看上去還是IOVA連續的。由于重新映射，IOVA空間片段化的問題就變得無關緊要。不管物理內存被分段得多么嚴重，它總能被重新映射為IOVA-連續的大塊內存。

圖4.作為VA的IOVA模式下的分段示例。

作為VA的IOVA模式還有另一個優點，它不需要任何權限。這是因為它不需要訪問系統頁面映射。這樣就可以允許以非root用戶身份運行DPDK，而且在特權訪問不受歡迎的環境中，如云原生環境就可以更加容易地使用DPDK。

當然, 作為VA的IOVA模式也有一個缺點。出于各種原因，有時候可能不能選擇使用IOMMU。這種情況可能包括：

· 硬件不支持IOMMU

· 平臺可能本身就沒有IOMMU（比如沒有IOMMU模擬的VM）

·軟件設備（例如，DPDK的內核網絡接口（KNI）PMD）不支持作為VA的IOVA模式

· 一些IOMMU（通常是模擬的IOMMU）的地址寬度可能有限，雖然這不妨礙用作VA的IOVA模式，但限制了其有效性

· 在非Linux *的操作系統上使用DPDK

但是，這些情況還是相對較少，絕大多數情況下，作為VA的IOVA模式都可以正常工作。

IOVA模式的選擇

很多情況下，DPDK默認選擇作為PA的IOVA模式，因為從硬件角度這是最安全的模式。所有給定的硬件（或軟件）PMD至少都可以保證支持作為PA的IOVA模式。盡管如此，如果條件允許，還是強烈建議所有DPDK用戶使用作為VA的IOVA模式，畢竟此模式具有不可否認的優勢。

但是，用戶不必非要在兩者中選擇一個?？梢宰詣訖z測出最合適的IOVA模式，而且默認選項絕對適用于大多數情況，因此不需要用戶來做此選擇。如果默認選項并不合適，用戶可以使用--iova-mode EAL命令行參數嘗試使用EAL標志（適用于DPDK 17.11及更高版本）來代替IOVA模式：

1./app --iova-mode=pa # use IOVA as PA mode

2./app --iova-mode=va # use IOVA as VA mode

大多數情況下，VA和PA模式不會互相排斥，可以使用任一模式，但在某些情況下，作為PA模式的IOVA是唯一可用的選擇。當不能使用作為VA模式的IOVA時，即使EAL參數要求使用作為VA模式的IOVA，DPDK也會自動切換為作為PA模式的IOVA。

DPDK還提供了一個API，可查詢運行時正在使用的IOVA模式，但通常這不會在用戶應用中使用，因為只有像是DPDK PMD和總線驅動程序才會要求獲取這種信息。

IOVA模式和DPDK PCI驅動程序

DPDK本身并不執行所有硬件設備寄存器和中斷映射，它需要內核的幫助。為此，DPDK要使用的所有硬件設備都需要綁定到一個通用外圍組件互連（Peripheral Component Interconnect, PCI）內核驅動程序。和一般的設備內核驅動程序不同的是，通用此驅動程序并未被鎖定到特定的PCI ID集，即針對某類設備的常規驅動程序，可以與任何類型的PCI設備一起使用。

要將設備綁定到通用驅動程序，DPDK用戶應該參考DPDK文檔。該文檔描述了在所有支持的操作系統中如何進行此項操作。但是，關于DPDK支持的各種用戶態IO驅動程序及其支持的IOVA模式，還需要有所說明。雖然內核驅動程序和支持的IOVA模式之間看起來可能存在1：1的對應關系，但事實并非如此。下面的部分將討論Linux上可用的驅動程序。

用戶空間IO（UIO）驅動程序

DPDK代碼庫中最早的內核驅動程序是igb_uio驅動程序。在DPDK最初的發展階段，這個驅動程序就已經存在了，因此它是DPDK開發人員使用最廣泛也是最熟悉的驅動程序。

此驅動程序依賴內核用戶空間IO（UIO）基礎結構運作，并為所有中斷類型（遺留、消息信號中斷（MSI）和MSI-X）提供支持，以及創建虛擬功能。它還公開硬件設備通過/dev/uio文件系統注冊和中斷句柄，然后DPDK EAL將它們用于將它們映射到用戶空間并使它們可用于DPDK PMD。

igb_uio驅動程序非常簡單，能做的也并不多，因此它不支持使用IOMMU也就不足為奇了。或者，更確切地說，它確實支持IOMMU，但僅在傳輸模式下，它在IOVA和物理內存地址之間建立1：1映射。igb_uio不支持使用完整的IOMMU模式。因此， igb_uio驅動程序僅支持IOVA作為PA模式，并且根本無法在IOVA中作為VA模式工作。

類似于igb_uio的驅動程序在內核中可用：uio_pci_generic。它的工作方式與igb_uio非常相似，只是它的功能更加有限。例如，igb_uio支持所有中斷類型（傳統，MSI和MSI） -X），而uio_pci_generic只支持遺留中斷。更重要的是，igb_uio可以創建虛擬函數(Virtual Function, VF)，而uio_pci_generic則不能;因此，如果在使用DPDK物理函數(Physical Function, PF)驅動程序時創建VF是必需的一步，igb_uio是唯一的選擇。

因此，在大多數情況下，igb_uio與uio_pci_generic相同或更可取。關于使用IOMMU的所有限制同樣適用于igb_uio和uio_pci_generic驅動程序 - 它們不能使用完整的IOMMU功能，因此僅支持IOVA作為PA模式。

VFIO內核驅動程序

上述驅動程序的替代方案是vfio-pci驅動程序。它是虛擬功能I / O（VFIO）內核基礎結構的一部分，并在Linux 3.6版中引入。VFIO基礎設施使設備寄存器和設備中斷可供用戶空間應用程序使用，并可使用IOMMU設置IOVA映射以從用戶空間執行IO。后一部分至關重要 - 此驅動程序專為與IOMMU一起使用而開發，在較舊的內核上，如果沒有啟用IOMMU，它甚至都無法工作。

與直觀看法相反，使用VFIO驅動程序允許使用IOVA作為PA和IOVA作為VA模式。這是因為，雖然建議使用IOVA作為VA模式來利用該模式的所有好處，但沒有什么能阻止DPDK的設置IOMMU映射的EAL以遵循物理內存布局1：1的方式;畢竟IOVA映射是任意的。在這種情況下，即使使用IOMMU，DPDK也可以在IOVA中作為PA模式工作，從而允許DPDK KNI等工作。但是，仍然需要root權限才能將IOVA用作PA模式。

在更新的內核（4.5+，向后移植到一些舊版本）上，有一enable_unsafe_noiommu_mode選項，允許在沒有IOMMU的情況下使用VFIO。這種模式適用于與基于UIO的驅動程序相同的所有意圖和目的，并具有所有相同的優點與限制。

內核驅動程序的選擇

一般來說，在應用的角度我們并不需要選擇內核驅動程序。通常來說，內核驅動程序的選擇是由具體的情況來決定的。下面的流程圖可以幫助決定在哪些特定情況下可以使用哪個驅動程序：

圖5.通用PCI內核驅動程序選擇流程圖。

如圖5所示，很明顯應該在幾乎所有的情況下都使用VFIO驅動程序，尤其是在生產環境中。IOMMU在硬件級別可提供設備隔離，這可以讓使用DPDK的應用程序更加安全，而作為VA的IOVA模式則可以通過重新映射讓內存得到更好的利用，而且不需要root權限來運行DPDK應用。但是，某些用例需要igb_uio或uio_pci_generic驅動程序。

軟件輪詢模式驅動程序（PMD）

除此之外，DPDK附帶的一系列軟件PMD不需要通用內核PCI驅動程序，而是依靠標準內核基礎架構來提供硬件支持。這樣一來，DPDK幾乎可以與任何硬件同時使用，即使DPDK本身不支持它。

PCAP庫是用于網絡硬件的廣泛使用和支持的數據包捕獲庫。目前，DPDK具有可用于PCAP庫的PMD。DPDK還支持具有AF_PACKET PMD的Linux網絡，而且還可以在DPDK中本地支持AF_XDP。雖然使用這些PMD會有性能成本（有時相當可觀的），但其優點是設置很容易，而且這些PMD一般完全不在乎IOVA模式。

總結

本文深入介紹了DPDK如何處理物理內存，也概述了在使用各種Linux *內核驅動程序時DPDK提供的物理尋址功能。