On Mon, 9 Feb 2026 at 12:51, Eli Britstein <[email protected]> wrote: > On 09/02/2026 13:17, David Marchand wrote: > > External email: Use caution opening links or attachments > > > > > > By default, DPDK probes all available resources (like PCI devices) and > > partially initialises them (/ takes over them). > > This behavior has been relied on by OVS, since netdev-dpdk introduction. > > It is not really needed anymore since DPDK device hotplug has been > > supported for some time now. > > > > Besides, this initial probing may not be desirable: > > - for PCI devices bound to vfio-pci, the first application taking over > > them "wins", meaning that OVS would prevent qemu from using some VF > > devices, > > - for mlx5 devices, the driver maintains link status and liveness > > of all ports (taking some kernel lock) even when OVS only uses > > a subset of them, > > Not only that: > > - if we want to use dpdk devargs, they cause issues as the ports were > already probed with their defaults in the initial probe.
Yes, passing such options kind of require to set them all from the start in other_config:dpdk-extra.. That's something I could add in the commitlog. > > - devices that may be dynamic (SFs for example) are probed at init, but > if the SF is destroyed/re-created, it is not re-probed, making it to be > non-functional. > Note: DPDK also probes other busses. This patch (as well as mine [1]) > only handles PCI. In our downstream version we also add "-a > auxiliary:mlx5_core.sf.0" to disable auxiliary bus probes. > > I didn't include that in my patch as it seemed too "vendor specific", > though re-thinking about it, there is no harm. WDYT? I don't know if there are NXP users of ovs, but grout uses the invalid allow list trick for the fslmc bus too (-a fslmc:dpni.65535). If OVS and grout both express the same need, a change on DPDK bus API side seems necessary. But waiting for this to happen, it would be acceptable for me to have this for the auxiliary bus in OVS under a OVS option. As for the redundant aspect of the dpdk-probe-at-init option I propose compared to suggesting users to hack with -a 0000 if their setup gets broken by this change in behavior: I find this option clearer from a user pov rather than have them disable/workaround bus per bus. Keeping on relying on the magical -a 0000: trick seems dangerous to me as it relies on DPDK internals. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
