[dpdk-dev] atomic operations
Stephen Hemminger
stephen at networkplumber.org
Sat Jul 3 19:30:41 CEST 2021
On Sat, 03 Jul 2021 13:29:38 +0200
Thomas Monjalon <thomas at monjalon.net> wrote:
> In the deprecation notices of DPDK 21.05, we can still read this:
> "
> * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does
> not allow for writing optimized code for all the CPU architectures supported
> in DPDK. DPDK will adopt C11 atomic operations semantics and provide wrappers
> using C11 atomic built-ins. These wrappers must be used for patches that
> need to be merged in 20.08 onwards. This change will not introduce any
> performance degradation.
>
> * rte_smp_*mb: These APIs provide full barrier functionality. However, many
> use cases do not require full barriers. To support such use cases, DPDK will
> adopt C11 barrier semantics and provide wrappers using C11 atomic built-ins.
> These wrappers must be used for patches that need to be merged in 20.08
> onwards. This change will not introduce any performance degradation.
> "
>
> Should we keep these notifications forever?
>
> It is very difficult to find which wrapper to use.
>
> This is the guide we have:
> https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks-and-atomic-operations
> There are 2 blog posts:
> https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory-model/
> https://www.dpdk.org/blog/2021/06/09/reader-writer-concurrency/
>
> Basically it says we should use "__atomic builtins" but there is example
> for simple situations like counters, memory barriers, etc.
> Please who could work on improving the documentation?
>
>
Maybe there needs to be a DPDK version of the infamous kernel documentation
of memory barriers.
More information about the dev
mailing list