On Tue, 29 Sep 2026 10:07:09 +0200 David Marchand <[email protected]> wrote:
> 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. > """ > AI wants all DPDK statistics to use atomic, but that is not the model we use in DPDK. DPDK trades off performance for the potential for inexact statistics. The commit message says that. This is a false positive.
