On 18/06/2026 17:22, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
On 15 Jun 2026, at 14:18, David Marchand wrote:
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?
Ack. I'll use one mutex (renamed to "dpdk_common_mutex") for both.
I also have some doubt on moving the mutex to the shared code. Can we
keep the dev->mutex in each netdev implementations?
Why? We need to access to this mutex from common dpdk/doca code.
- 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.
Ack
And rename netdev-dpdk-private.h as netdev-dpdk-common.h.
Ack
- 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).
Ack
- The fastpath code rx/tx could probably be shared via an inline helper.
For RX there is no much in common. For TX, ack.
- 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.
This was the case in v3. I moved it back to be in common since watchdog
for example is common and needs to know if to check link state or not. I
thought thought it was redundant for doca we could keep it for simplicity.
However, I'll add another pre-step commit to get rid of this field
entirely so it won't be neither in common nor dpdk.
Hi Eli,
Just want to make sure the points above are clear to you before you send out
a v5. Maybe we need some more discussion on the mailing list regarding these?
Please see my replies above. If there are more comments please send
them. Thanks.
Cheers,
Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
