[PATCH v8 04/25] net/ena: replace use of rte_atomicNN

[David Marchand]

On Thu, 17 Sept 2026 at 22:12, Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> Convert the legacy rte_atomicNN operations to stdatomic.
> * Remove variable ena_alloc_cnt is defined by not used.
>   It is a leftover from previous memzone naming scheme.
>
> * Convert the legacy rte_atomic32_t and rte_atomic32_{inc,dec,set,read}
>   macros to C11 stdatomic equivalents.
>   Memory ordering is kept at seq_cst,
>   matching the implicit ordering of the legacy API.
>
> * Do not use rte_atomic for statistics
>  The DPDK PMD model is that statistics do not have to be exact
>  in face of contention.

AI complains about the change:
"""
While the DPDK guidelines do accept that statistics may be approximate
under contention, the problem here is that **concurrent non-atomic
increments are undefined behavior in C**. Multiple Rx queues (each
potentially on different lcores) can increment `ierrors`
simultaneously. A non-atomic `++` involves a read-modify-write
sequence that is not atomic, leading to:
- Lost updates (the classic lost-update problem)
- Potential torn reads/writes on some architectures

The correct approach would be to use `rte_atomic_fetch_add_explicit()`
with `rte_memory_order_relaxed`. Relaxed ordering is appropriate for
statistics counters where approximate values are acceptable, but the
operation must still be atomic to avoid undefined behavior.
"""

-- 
David Marchand