On 9 Feb 2026, at 14:16, Eli Britstein via dev wrote:
> 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.
Wouldn't it be convenient to have a DPDK option to not probe any bus? This
would solve the workarounds cleanly.
Also, will we be creating any problems for existing users? i.e. do all
currently supported drivers support hotplug?
//Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
