dpdk PA和IOVA模式

1. introduction

在使用testpmd的时候, 发现--iova-mode=pa这个参数, 本篇文章主要介绍iova和pa的定义及其区别。

IOMMU

IOMMU就是MMU+IO。 作用和MMU是一样的, 将虚拟地址翻译成物理地址。不一样的是, MMU被CPU所使用, 而IOMMU被设备所使用。

2. PA与IOVA

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模式。

2.1 作为物理地址（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！”

2.2作为虚拟地址（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模式都可以正常工作。

reference:
IOVA
IOMMU introduction
段页式管理