On Thu, 17 Sept 2026 at 22:12, Stephen Hemminger <[email protected]> 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
