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.
--
David Marchand
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
