On Mon, 18 May 2026 at 13:39, Eli Britstein <[email protected]> wrote: > > Introduce a new netdev type - netdev-doca. > In order to compile, need to install doca on the build machine. > > > v2-v1: > - Fixed licence comment headers. > - Abandoned dpdk-extra patch. It is a configuration issue and there is > also [1]. > - Added co-author to some of the commits. > > [1] https://mail.openvswitch.org/pipermail/ovs-dev/2026-February/430134.html > > v3-v2: > - There is a lot of code that can be shared with netdev-dpdk. Refactored it > to enable sharing. > - Added documentation files. > - Styling fixes. > - Reworked ovs-rcu and refmap patches. > - Added support for github actions (CI) to compile with doca. > - Simplified acinclude.m4. > - Reworked sysfs access. Most of the accesses are now with doca-API. > - Reworked error paths - returned values, messages and rollbacks. > > v4-v3: > - Licence comment headers. > - Styling fixes. > - CI dpdk is enhanced to compile mlx5 PMD and used with doca jobs. > - Removed ovs-rcu patch. > - Refmap fixes. > - DOCA mempool free by sweep.
Thanks for the series. - I would like to make sure what the needs are on the locking side. Today, we have a dpdk_mutex protecting the netdev_dpdk list, and at the same time, serialising calls to ethdev API iiuc. DOCA has its own list and objects to protect. But in the end I don't think we need two separate mutex. We don't expect doca and dpdk mutexes to conflict at runtime, do we? I also have some doubt on moving the mutex to the shared code. Can we keep the dev->mutex in each netdev implementations? - There are still many places that can be factorized, like the netdev objects construct/init/config code. It is worth moving all the control path code into a netdev-dpdk-common.c file, and wrapping around in dpdk/doca specific implementations. And rename netdev-dpdk-private.h as netdev-dpdk-common.h. - The mempool creation code seems orthogonal and can be moved to netdev-dpdk-common.c (the per_port_memory stuff can be hidden or reworked). - The fastpath code rx/tx could probably be shared via an inline helper. - The dev_type field in netdev_dpdk_common is only there to protect the netdev_dpdk objects backed by a vhost-user port. This is something that should remain in netdev_dpdk only. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
