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