summaryrefslogtreecommitdiff
path: root/doc/guides/prog_guide/env_abstraction_layer.rst
diff options
context:
space:
mode:
authorDavid Marchand <david.marchand@redhat.com>2019-07-22 14:56:51 +0200
committerThomas Monjalon <thomas@monjalon.net>2019-07-22 17:45:52 +0200
commitb76fafb174d2cd5247c3573bb3d49444e195e760 (patch)
treecdb2f1ac9bf344e0a35fa38d5d843b7e42d18410 /doc/guides/prog_guide/env_abstraction_layer.rst
parent62f8f5ace506b336afcb9022d4c456f893f1d732 (diff)
downloaddpdk-b76fafb174d2cd5247c3573bb3d49444e195e760.zip
dpdk-b76fafb174d2cd5247c3573bb3d49444e195e760.tar.gz
dpdk-b76fafb174d2cd5247c3573bb3d49444e195e760.tar.xz
eal: fix IOVA mode selection as VA for PCI drivers
The incriminated commit broke the use of RTE_PCI_DRV_IOVA_AS_VA which was intended to mean "driver only supports VA" but had been understood as "driver supports both PA and VA" by most net drivers and used to let dpdk processes to run as non root (which do not have access to physical addresses on recent kernels). The check on physical addresses actually closed the gap for those drivers. We don't need to mark them with RTE_PCI_DRV_IOVA_AS_VA and this flag can retain its intended meaning. Document explicitly its meaning. We can check that a driver requirement wrt to IOVA mode is fulfilled before trying to probe a device. Finally, document the heuristic used to select the IOVA mode and hope that we won't break it again. Fixes: 703458e19c16 ("bus/pci: consider only usable devices for IOVA mode") Signed-off-by: David Marchand <david.marchand@redhat.com> Reviewed-by: Jerin Jacob <jerinj@marvell.com> Tested-by: Jerin Jacob <jerinj@marvell.com> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Diffstat (limited to 'doc/guides/prog_guide/env_abstraction_layer.rst')
-rw-r--r--doc/guides/prog_guide/env_abstraction_layer.rst31
1 files changed, 31 insertions, 0 deletions
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index f15bcd9..1d63675 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -419,6 +419,37 @@ Misc Functions
Locks and atomic operations are per-architecture (i686 and x86_64).
+IOVA Mode Detection
+~~~~~~~~~~~~~~~~~~~
+
+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.
+
+For the first step, EAL asks each bus its requirement in terms of IOVA mode
+and decides on a preferred IOVA mode.
+
+- if all buses report RTE_IOVA_PA, then the preferred IOVA mode is RTE_IOVA_PA,
+- if all buses report RTE_IOVA_VA, then the preferred IOVA mode is RTE_IOVA_VA,
+- if all buses report RTE_IOVA_DC, no bus expressed a preferrence, then the
+ preferred mode is RTE_IOVA_DC,
+- if the buses disagree (at least one wants RTE_IOVA_PA and at least one wants
+ RTE_IOVA_VA), then the preferred IOVA mode is RTE_IOVA_DC (see below with the
+ check on Physical Addresses availability),
+
+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.
+
+- 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.
+
IOVA Mode Configuration
~~~~~~~~~~~~~~~~~~~~~~~