On Mon, Feb 27, 2023 at 5:13 PM Gaëtan Rivet <gr...@u256.net> wrote: > Ah ok, so if I understand correctly, DPDK would need to declare some > '__rte_lockable rte_mutex' and associated functions for transparent support, > to wrap above the pthread API.
Yes, this is what I had in mind for the mid/long term but it was too late for 23.03 after -rc1. The Windows porting effort will probably need this abstraction too as we are trying to stop relying on the pthread API. I don't see this item in Microsoft roadmap, though. > > Unless it happens, would it be possible to condition the thread-safety > annotations > to FREEBSD as well? > > Maybe have two versions of the annotations: > > __rte_exclusive_locks_required() /* Conditioned on clang */ > __pthread_exclusive_locks_required() /* Conditioned on glibc/pthread > support */ > > the first one to use on RTE types that can be declared with __rte_lockable, > the second for pthread objects that we don't want to replace. > I know the namespace is not great so maybe named another way. > > The '#ifdef FREEBSD' ossifies the annotation support at the function level, > when this is a matter of types. This impedance mismatch would mean large > changes if someone was to make this support evolve at some point. I don't see how it requires large changes with the current approach. The patches in this series are a matter of lines. If we come up with the right abstraction later, this uglyness will be removed. In any case, I am running short of time for 23.03. I am missing reviews from driver maintainers, which is a pity. Thomas raised an eyebrow on the malloc: and mem: patches too. I will probably defer this series to the next release. -- David Marchand
