IOVA Mode is selected by considering what the current usable Devices on the
system require and/or support.
-Below is the 2-step heuristic for this choice.
+On FreeBSD, RTE_IOVA_PA is always the default. On Linux, the IOVA mode is
+detected based on a 2-step heuristic detailed below.
For the first step, EAL asks each bus its requirement in terms of IOVA mode
and decides on a preferred IOVA mode.
RTE_IOVA_VA), then the preferred IOVA mode is RTE_IOVA_DC (see below with the
check on Physical Addresses availability),
+If the buses have expressed no preference on which IOVA mode to pick, then a
+default is selected using the following logic:
+
+- if physical addresses are not available, RTE_IOVA_VA mode is used
+- if /sys/kernel/iommu_groups is not empty, RTE_IOVA_VA mode is used
+- otherwise, RTE_IOVA_PA mode is used
+
+In the case when the buses had disagreed on their preferred IOVA mode, part of
+the buses won't work because of this decision.
+
The second step checks if the preferred mode complies with the Physical
Addresses availability since those are only available to root user in recent
-kernels.
+kernels. Namely, if the preferred mode is RTE_IOVA_PA but there is no access to
+Physical Addresses, then EAL init fails early, since later probing of the
+devices would fail anyway.
+
+.. note::
+
+ The RTE_IOVA_VA mode is preferred as the default in most cases for the
+ following reasons:
+
+ - All drivers are expected to work in RTE_IOVA_VA mode, irrespective of
+ physical address availability.
+ - By default, the mempool, first asks for IOVA-contiguous memory using
+ ``RTE_MEMZONE_IOVA_CONTIG``. This is slow in RTE_IOVA_PA mode and it may
+ affect the application boot time.
+ - It is easy to enable large amount of IOVA-contiguous memory use-cases
+ with IOVA in VA mode.
+
+ It is expected that all PCI drivers work in both RTE_IOVA_PA and
+ RTE_IOVA_VA modes.
-- if the preferred mode is RTE_IOVA_PA but there is no access to Physical
- Addresses, then EAL init fails early, since later probing of the devices
- would fail anyway,
-- if the preferred mode is RTE_IOVA_DC then based on the Physical Addresses
- availability, the preferred mode is adjusted to RTE_IOVA_PA or RTE_IOVA_VA.
- In the case when the buses had disagreed on the IOVA Mode at the first step,
- part of the buses won't work because of this decision.
+ If a PCI driver does not support RTE_IOVA_PA mode, the
+ ``RTE_PCI_DRV_NEED_IOVA_AS_VA`` flag is used to dictate that this PCI
+ driver can only work in RTE_IOVA_VA mode.
IOVA Mode Configuration
~~~~~~~~~~~~~~~~~~~~~~~
Alternatively, applications can use the lock-free stack mempool handler. When
considering this handler, note that:
- - It is currently limited to the x86_64 platform, because it uses an
- instruction (16-byte compare-and-swap) that is not yet available on other
+ - It is currently limited to the aarch64 and x86_64 platforms, because it uses
+ an instruction (16-byte compare-and-swap) that is not yet available on other
platforms.
- It has worse average-case performance than the non-preemptive rte_ring, but
software caching (e.g. the mempool cache) can mitigate this by reducing the