DPDK內(nèi)存管理的IOMMU和IOVA技術(shù)總結(jié)

之前寫過DPDK相關(guān)內(nèi)存管理的代碼分析，但是隨著DPDK的版本迭代在內(nèi)存管理方面也在進(jìn)行著不斷的演進(jìn)。這里結(jié)合一些參考文章再對DPDK的內(nèi)存使用方式和發(fā)展變化做一個階段性的總結(jié)。

大頁

DPDK通常是使用大頁（hugepage）內(nèi)存的，無論是2M的大頁還是1G的大頁，本質(zhì)上都是為了減少TLB miss，通過更大的page size來提升TLB的命中率，而TLB就是用來緩存頁表的高速緩存。

DMA

我們知道計算機(jī)的設(shè)備，如網(wǎng)卡硬件是不能處理用戶空間的虛擬地址（只有CPU通過頁表轉(zhuǎn)換MMU才能識別虛擬地址），因為它不能感知任何用戶態(tài)的進(jìn)程和其所分配到的用戶空間虛擬地址。相反，它只能訪問真實的物理地址上的內(nèi)存。

出于對效率的考量，現(xiàn)代硬件幾乎總是使用直接內(nèi)存存取（DMA）事務(wù)。通常，為了執(zhí)行一個DMA事務(wù)，內(nèi)核需要參與創(chuàng)建一個支持DMA的存儲區(qū)域，將進(jìn)程內(nèi)虛擬地址轉(zhuǎn)換成硬件能夠理解的真實物理地址，并啟動DMA事務(wù)。這是大多數(shù)現(xiàn)代操作系統(tǒng)中輸入輸出的工作方式；然而，這是一個耗時的過程，需要上下文切換、轉(zhuǎn)換和查找操作，這不利于高性能輸入/輸出。

DPDK的內(nèi)存管理以一種簡單的方式解決了這個問題。每當(dāng)一個內(nèi)存區(qū)域可供DPDK使用時，DPDK就通過詢問內(nèi)核來計算它的物理地址，即DPDK維護(hù)了虛擬地址和物理地址的一個映射關(guān)系，由于DPDK使用鎖定（如vfio_pin_map_dma）內(nèi)存（防止物理內(nèi)存和虛擬內(nèi)存的映射關(guān)系變化），來使底層內(nèi)存區(qū)域的物理地址不會改變，因此硬件可以依賴這些物理地址始終有效，即使內(nèi)存本身有一段時間沒有使用。然后，DPDK會在準(zhǔn)備由硬件完成的輸入/輸出事務(wù)時使用這些物理地址，并以允許硬件自己啟動DMA事務(wù)的方式配置硬件。這使DPDK避免不必要的開銷，并且完全從用戶空間執(zhí)行輸入/輸出。

IOMMU和IOVA

默認(rèn)情況下，任何硬件都可以訪問整個系統(tǒng)的物理內(nèi)存，因此它可以在任何地方執(zhí)行DMA事務(wù)。這有許多安全隱患。例如，流氓和/或不可信進(jìn)程(包括在VM (虛擬機(jī))內(nèi)運行的進(jìn)程)可能使用硬件設(shè)備來讀寫內(nèi)核空間，和幾乎其他任何存儲位置。為了解決這個問題，現(xiàn)代系統(tǒng)配備了輸入輸出內(nèi)存管理單元(IOMMU)。這是一種硬件設(shè)備，提供DMA地址轉(zhuǎn)換和設(shè)備隔離功能，因此只允許特定設(shè)備執(zhí)行進(jìn)出特定內(nèi)存區(qū)域(由IOMMU指定)的DMA事務(wù)，而不能訪問指定訪問之外的系統(tǒng)內(nèi)存地址空間。

由于IOMMU的參與，硬件使用的物理地址可能不是真實的物理地址，而是IOMMU分配給硬件的(完全任意的)輸入輸出虛擬地址(IOVA)。一般來說，DPDK社區(qū)可以互換使用物理地址和IOVA這兩個術(shù)語，但是根據(jù)上下文，這兩者之間的區(qū)別可能很重要。例如，DPDK 17.11和更新的DPDK長期支持(LTS)版本在某些情況下可能根本不使用實際的物理地址，而是使用用戶空間虛擬地址來實現(xiàn)DMA。IOMMU負(fù)責(zé)地址轉(zhuǎn)換，因此硬件永遠(yuǎn)不會注意到兩者之間的差異。

如上圖所示，P1和P2進(jìn)程分別用虛擬地址P進(jìn)行DMA，由于IOMMU將虛擬地址P映射到不同的物理地址，所以這并不會沖突，而P3訪問的地址P并沒有在IOMMU中建立映射關(guān)系，所以DMA訪問會導(dǎo)致失敗。

IO虛擬地址（IOVA）模式

DPDK是一個用戶態(tài)應(yīng)用框架，使用DPDK的軟件可以像其他軟件一樣使用常規(guī)虛擬地址。但除此之外，DPDK還提供了用戶態(tài)PMD和一組API，以實現(xiàn)完全以用戶態(tài)執(zhí)行IO操作。前文也已經(jīng)提到過，硬件不能識別用戶空間虛擬地址;它使用的是IO地址——物理地址（PA）或IO虛擬地址（IOVA）。

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

PA作為IOVA模式

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

然而，作為PA的IOVA模式也存在一些缺點。其中一個就是它需要根用戶特權(quán)——如果無法訪問系統(tǒng)的頁面映射（因為DPDK要維護(hù)虛擬地址和物理地址IOVA的對應(yīng)關(guān)系），DPDK就無法獲取內(nèi)存區(qū)域的真實物理地址。因此，如果系統(tǒng)中沒有root權(quán)限，就無法以該模式運行。

PA作為IOVA的模式

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

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

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

VA作為IOVA模式

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

作為VA的IOVA模式。

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

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

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

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

1)硬件不支持IOMMU；

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

3)軟件設(shè)備（例如，DPDK的內(nèi)核網(wǎng)絡(luò)接口（KNI）PMD）不支持作為VA的IOVA模式；

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

5)在非Linux *的操作系統(tǒng)上使用DPDK；

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

IOVA模式的選擇

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

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

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

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

大多數(shù)情況下，VA和PA模式不會互相排斥，可以使用任一模式，但在某些情況下，PA作為IOVA的模式是唯一可用的選擇。當(dāng)不能使用作為VA模式的IOVA時，即使EAL參數(shù)要求使用作為VA模式的IOVA，DPDK也會自動切換為作為PA模式的IOVA。DPDK還提供了一個API，可查詢運行時正在使用的IOVA模式，但通常這不會在用戶應(yīng)用中使用，因為只有像是DPDK PMD和總線驅(qū)動程序才會要求獲取這種信息。

UIO和VFIO對IOVA的支持

lIgb_uio

DPDK代碼庫中最早的內(nèi)核驅(qū)動程序是igb_uio驅(qū)動程序。在DPDK最初的發(fā)展階段，這個驅(qū)動程序就已經(jīng)存在了，因此它是DPDK開發(fā)人員使用最廣泛也是最熟悉的驅(qū)動程序。

此驅(qū)動程序依賴內(nèi)核用戶空間IO（UIO）基礎(chǔ)結(jié)構(gòu)運作，并為所有中斷類型（INT、消息信號中斷（MSI）和MSI-X）提供支持，以及創(chuàng)建虛擬功能。它還公開硬件設(shè)備通過/dev/uio文件系統(tǒng)注冊和中斷句柄，然后DPDK EAL將它們用于將它們映射到用戶空間并使它們可用于DPDK PMD。

gb_uio驅(qū)動程序非常簡單，能做的也并不多，因此它不支持使用IOMMU?；蛘撸_切地說，它確實支持IOMMU，但僅在傳輸模式下，它在IOVA和物理內(nèi)存地址之間建立1：1映射。igb_uio不支持使用完整的IOMMU模式。因此，igb_uio驅(qū)動程序僅支持PA作為IOVA模式，并且根本無法在IOVA中作為VA模式工作。

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

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

lvfio

vfio-pci驅(qū)動是虛擬功能I / O（VFIO）內(nèi)核基礎(chǔ)結(jié)構(gòu)的一部分，并在Linux 3.6版中引入。VFIO使設(shè)備寄存器和設(shè)備中斷可供用戶空間應(yīng)用程序使用，并可使用IOMMU設(shè)置IOVA映射以從用戶空間執(zhí)行IO。后一部分至關(guān)重要，此驅(qū)動程序?qū)榕cIOMMU一起使用而開發(fā)，在較舊的內(nèi)核上，如果沒有啟用IOMMU，它甚至都無法工作。

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

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

17.11及早期版本

使用DPDK庫17.11版本或更早版本的任何應(yīng)用程序必須事先知道其內(nèi)存要求。這是因為，對于這些版本的DPDK，在初始化之后不可能再申請額外的大頁內(nèi)存，或者將其釋放回系統(tǒng)。因此，DPDK應(yīng)用程序可能使用的任何內(nèi)存都必須在應(yīng)用程序初始化時預(yù)留，并在應(yīng)用程序的整個生命周期都由DPDK保留。

在決定要保留的內(nèi)存量時，留出一些余量通常是個好主意。在各種內(nèi)部分配中，某些DPDK內(nèi)存將在不同的內(nèi)部分配中被“浪費”，數(shù)量會因您的配置而異（DPDK將使用的設(shè)備數(shù)量，啟用功能等）。

此外，DPDK17.11中的大多數(shù)API都需要大量的IOVA連續(xù)內(nèi)存。這是因為在DPDK 17.11中，虛擬內(nèi)存布局總是與物理內(nèi)存布局相匹配。換句話說，如果使用PA作為IOVA，則要求PA是連續(xù)的。這是DPDK17.11內(nèi)存管理中眾所周知的問題之一：實際上很少有應(yīng)用程序需要PA連續(xù)內(nèi)存，由于缺少足夠的IOVA連續(xù)內(nèi)存，分配大量內(nèi)存可能會失敗。

IOVA模式的比較

上述限制當(dāng)然僅適用于作為物理地址（PA）模式的IOVA，因為在該模式下，DPDK的虛擬地址（VA）空間遵循PA空間的布局。在PA模式的IOVA中，可用IOVA連續(xù)內(nèi)存量取決于DPDK控制之外的許多因素，盡管DPDK將嘗試保留盡可能多的IOVA連續(xù)內(nèi)存，具體取決于可用內(nèi)存量和系統(tǒng)配置，可能沒有足夠的IOVA連續(xù)內(nèi)存來滿足所有分配。

在VA模式的IOVA中，這不是問題，因為在這種情況下，IOVA空間布局將與VA空間的布局相匹配（而不是相反），并且所有物理內(nèi)存都被重新映射為IOVA連續(xù)到硬件。

18.11及之后版本

動態(tài)內(nèi)存管理

DPDK 18.11的最大變化是可以在運行時增加和減少內(nèi)存使用量，從而消除了DPDK內(nèi)存映射為靜態(tài)的情況，這帶來了許多可用性方面的改進(jìn)。

在DPDK 17.11中，運行沒有任何環(huán)境抽象層（EAL）參數(shù)的DPDK應(yīng)用會保留所有可用的大頁內(nèi)存供其使用，且不會為其他應(yīng)用程序或其他DPDK實例留下任何大頁內(nèi)存。對于DPDK18.11而言情況有所不同，DPDK僅保留應(yīng)用運行所必須的內(nèi)存量。在這種意義上，DPDK現(xiàn)在性能更好，并且使DPDK與其他應(yīng)用程序完美配合所需的工作也更少。

同樣，不再需要事先知道應(yīng)用程序的內(nèi)存需求，DPDK的內(nèi)存映射可以動態(tài)增加和減少，因此DPDK內(nèi)存子系統(tǒng)可以根據(jù)需要自動增加其內(nèi)存使用量，并在不再需要時將內(nèi)存返回給系統(tǒng)。這意味著部署DPDK應(yīng)用程序所需的工作更少，因為現(xiàn)在DPDK可以自行管理其內(nèi)存需求。
DPDK 18.11和IOVA連續(xù)性

DPDK 18.11中的一項基本后臺更改是，不能保證虛擬地址（VA）連續(xù)內(nèi)存是IOVA連續(xù)的；兩者之間不再有任何關(guān)聯(lián)。在VA作為IOVA的模式下，IOVA布局仍然像以前一樣遵循VA布局，但是在PA作為IOVA的模式下，PA布局是任意的（物理頁面要向后映射并不罕見）。

DPDK版本之間的IOVA（PA模式）布局比較

這種改變并不像看起來那樣具有顛覆性，因為實際上沒有多少數(shù)據(jù)結(jié)構(gòu)需要IOVA連續(xù)內(nèi)存。所有軟件數(shù)據(jù)結(jié)構(gòu)（環(huán)，內(nèi)存池，哈希表等）僅需要VA連續(xù)內(nèi)存，而不在意底層物理內(nèi)存布局。這使得在早期DPDK版本上工作的大多數(shù)用戶應(yīng)用程序可以無縫過渡到新版本，而無需更改代碼。

盡管如此，某些數(shù)據(jù)結(jié)構(gòu)確實需要IOVA連續(xù)內(nèi)存（例如，硬件隊列結(jié)構(gòu)），對于這些情況，引入了新的分配器標(biāo)志。使用此標(biāo)志，可以使memzone分配器嘗試分配IOVA連續(xù)的內(nèi)存。

單個文件段

較舊的DPDK版本在hugetlbfs文件系統(tǒng)中的每個大頁上存儲一個文件，這適用于大多數(shù)用例，但有時會出現(xiàn)問題，特別是，vhost-user后端的Virtio將與后端共享文件，并且有可共享文件描述符數(shù)量的硬性限制。當(dāng)使用大頁（例如1 GB的頁面）時，它可以很好地工作，但是在頁面大小較小的情況下，文件數(shù)量會很快超過文件描述符限制。

為了解決此問題，版本18.11中引入了一種新模式，即單文件段模式，該模式通過--single-file-segmentsEAL命令行標(biāo)志啟用，這使得EAL在hugetlbfs中創(chuàng)建的文件更少，并且使具有vhost-user后端的Virtio甚至可以在最小頁面大小下工作。