On 12 Feb 2026, at 12:14, Eli Britstein wrote:
> On 12/02/2026 13:05, David Marchand wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On Thu, 12 Feb 2026 at 11:55, Eli Britstein <[email protected]> wrote:
>>>>>>> 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).
>>> David - I tried to add this to see how DPDK behaves. It completely fails
>>> (probably I don't have this bus compiled).
>>>
>>> It means we can't add by default neither this nor the auxiliary trick I
>>> mentioned above (I compiled dpdk without it, and got a similar failure).
>>>
>>> 2026-02-12T10:30:24.231Z|00016|dpdk|ERR|EAL: failed to parse device
>>> "fslmc:dpni.65535"
>>> 2026-02-12T10:30:24.231Z|00017|dpdk|ERR|EAL: Unable to parse device
>>> 'fslmc:dpni.65535'
>>>
>>> 2026-02-12T10:45:01.704Z|00013|dpdk|ERR|EAL: failed to parse device
>>> "auxiliary:mlx5_core.sf.0"
>>> 2026-02-12T10:45:01.704Z|00014|dpdk|ERR|EAL: Unable to parse device
>>> 'auxiliary:mlx5_core.sf.0'
>>>
>>> rte_eal_init() fails and OVS aborts.
>>>
>>> I could not compile DPDK without PCI support, so I think this is valid,
>>> but not others.
>> Mm, you could put this under a #ifdef RTE_BUS_XXX, or query at runtime
>> which bus are available, via rte_bus_find_by_name().
> I think a ifdef is fine. Please wrap each case (also the PCI, just to be
> safe) with the right one.
Will this work when linking to dpdk dynamically?
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
