Re: [RFC 1/4] net/af_packet: remove volatile from statistics

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 2 Feb 2026 11:12:31 -0800
Scott Mitchell <scott.k.mitch1@gmail.com> wrote:

> Thank you for the clarification about the function pointer indirection
> acting as a compiler barrier - that makes sense for the typical case.
> 
> I have one remaining question about 32-bit architectures: even with
> the implicit barrier, plain uint64_t reads aren't atomic on 32-bit
> platforms (reader could see torn high/low halves). Is this acceptable
> for stats counters in DPDK, or is 32-bit support not a concern?

DPDK has not worried about torn counters on 32 bit architectures.
Whether it should or not is open question.
People don't care much about 32 bit anymore; other than not breaking it.

> For context, atomic_load/store(memory_order_relaxed) formally
> guarantees both visibility and no tearing across architectures, with
> minimal (GCC) or zero (Clang) overhead for x86-64. I see there's
> precedent in DPDK for plain uint64_t stats, and I'm hoping to
> understand the assumptions/trade-offs better.

The problems is that on relaxed ordering architectures like ARM
it makes the counter update more expensive in the fast path.