> From: David Marchand [mailto:[email protected]] > Sent: Saturday, 11 April 2026 12.11 > > On Fri, 10 Apr 2026 at 16:35, Morten Brørup <[email protected]> > wrote: > > > > Is there a workaround until this patch is added, if I don't want > rte_eal_init() to probe any devices, but I want my application to probe > devices later by calling rte_bus_scan() followed by rte_bus_probe()? > > > > It's not something we really need, so if you don't know it off the > top of your head, don't spend time trying to figure it out. > > Well, starting from the well known -a pci:0000:00:00.0 trick, I wrote > an incomplete workaround implemented for OVS. > https://patchwork.ozlabs.org/project/openvswitch/patch/20260226172429.2 > [email protected]/ > > Incomplete, because some buses make life harder with some additional > parsing restraints (bus/dpaa is the first one that comes to mind) or > requiring a driver handling the device exists (bus/platform which has > *no* in-tree driver, though this is a different story..).
Thanks for all the input, David. In my case it's only PCI bus devices, so I found a relatively simple workaround instead of using the "-a" trick. I start by not binding the devices to the vfio-pci kernel driver. Then I call rte_eal_init(); and the devices are not detected by the EAL at this point. Then I bind the devices to the vfio-pci kernel driver. And finally I call rte_bus_scan() and rte_bus_probe(); then the devices are detected at this point. Note: I have to pass "--iova-mode pa" to EAL init. Otherwise EAL init chooses VA mode, causing my drivers to not load, with the following message: "PCI_BUS: Expecting 'PA' IOVA mode but current mode is 'VA', not initializing" For anyone following the thread... During experimentation, I observed that if the devices were bound to the vfio-pci kernel driver, and "-a ..." was passed to rte_eal_init() it did - as expected - not load the drivers. However, when calling rte_bus_scan() and rte_bus_probe() afterwards, the drivers were also not auto-detected at this point. I guess the "-a ..." parameter is sticky, which makes sense. Anyway, looking forward to the --no-auto-probing EAL option. :-)
