[dpdk-dev] eal/pci: Improve automatic selection of IOVA mode
david.marchand at redhat.com
Mon Jun 3 12:48:58 CEST 2019
On Thu, May 30, 2019 at 7:48 PM Ben Walker <benjamin.walker at intel.com>
> In SPDK, not all drivers are registered with DPDK at start up time.
> Previously, that meant DPDK always chose to set itself up in IOVA_PA
> mode. Instead, when the correct iova choice is unclear based on the
> devices and drivers known to DPDK at start up time, use other heuristics
> (such as whether /proc/self/pagemap is accessible) to make a better
> This enables SPDK to run as an unprivileged user again without requiring
> users to explicitly set the iova mode on the command line.
Interesting, I got a bz on something similar the day you sent this patchset
- When a dpdk process is started, either it has access to physical
addresses or not, and this won't change for the rest of its life.
Your fix on defaulting to VA based on a rte_eal_using_phys_addrs() check
makes sense to me.
It is the most encountered situation when running ovs as non root on recent
- However, I fail to see the need for all of this detection code wrt
drivers and devices.
On one side of the equation, when dpdk starts, it checks physical address
On the other side of the equation, we have the drivers that will be invoked
when probing devices (either at dpdk init, or when hotplugging a device).
At this point, the probing call should check the driver requirement wrt to
the kernel driver the device is attached to.
If this requirement is not fulfilled, then the probing fails.
- This leaves the --iova-va forcing option.
Why do we need it?
If we don't have access to physical addresses, no choice but run in VA mode.
If we have access to physical addresses, the only case would be that you
want to downgrade from PA to VA.
But well, your process can still access it, not sure what the benefit is.
Jerin, I can see in the history you worked on this.
What did I miss?
Is there something wrong with dropping the detection code?
More information about the dev