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