On 09/02/2026 14:35, David Marchand wrote:
External email: Use caution opening links or attachments
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.
Agree.
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.
OK. I will abandon my patch then. Could you please add the missing
auxiliary and fslmc strings to your patch as well?
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.
I don't know how common that is. The con to have it is that having many
knobs, that almost nobody uses is an overhead to maintain etc.
I just thought that such users have to do some change (either this knob
or the "trick"), they can just do that and keep this old (bad) behavior
only for their scope.
--
David Marchand
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
