Re: [PATCH v2 1/4] net/af_packet: fix thread safety and frame calculations

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 28 Jan 2026 10:00:16 -0800
Scott Mitchell <scott.k.mitch1@gmail.com> wrote:

> On Wed, Jan 28, 2026 at 8:59 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Wed, 28 Jan 2026 01:36:04 -0800
> > scott.k.mitch1@gmail.com wrote:
> >  
> > > +/**
> > > + * Read tp_status from packet mmap ring. Matches kernel's READ_ONCE() with smp_rmb()
> > > + * ordering in af_packet.c __packet_get_status.
> > > + */
> > > +static inline uint32_t
> > > +tpacket_read_status(const volatile void *tp_status)
> > > +{
> > > +     rte_smp_rmb();
> > > +     return *((const volatile unaligned_uint32_t *)tp_status);
> > > +}  
> >
> > Wouldn't rte_compiler_barrier() be better choice here.
> > You are really only trying to keep compiler from optimzing the access.
> >
> > And tp_status is aligned in ring isn't it?  
> 
> The current approach replicates __packet_set_status and
> __packet_get_status [1] in the kernel which use the same barriers
> (WRITE_ONCE calls __write_once_size [2] which does a volatile cast).
> dpdk's rte_smp_rmb and rte_smp_wmb on x86 are just
> rte_compiler_barrier [3] but on arm it's different [4].
> 
> [1] https://github.com/torvalds/linux/blob/v6.18/net/packet/af_packet.c#L399-L451
> [2] https://github.com/torvalds/linux/blob/v6.18/tools/include/linux/compiler.h#L194
> [3] https://github.com/DPDK/dpdk/blob/v25.11/lib/eal/x86/include/rte_atomic.h#L26-L28
> [4] https://github.com/DPDK/dpdk/blob/v25.11/lib/eal/arm/include/rte_atomic_64.h#L29-L31

Agree that what ever primitive is used should match kernel.
Surprised kernel uapi doesn't export that some how.
FreeBSD explicitly states what atomic is needed in their similar ring api.