RE: [RFC 12/32] stack: always use C11 memory model implementation

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, 1 August 2026 19.02

> 
> On Fri, 31 Jul 2026 16:53:45 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > +TO: x86 maintainers, ThunderX maintainers
> >
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Wednesday, 29 July 2026 19.54
> > >
> > > The generic and C11 lock-free stack implementations differ only in
> > > memory ordering. The generic version uses a full barrier where its
> > > own comments state an acquire fence is sufficient, and seq_cst for
> > > all length counter operations.
> > >
> > > Only x86 and ThunderX still used the generic version. On x86 the
> > > switch removes a locked add per CAS attempt in push and pop; TSO
> > > provides the acquire semantics. On ThunderX the pop fence weakens
> > > from dmb ish to dmb ishld and the push fence goes away. Unlike the
> > > ring, no platform selected the generic stack for measured
> > > performance reasons.
> > >
> > > Remove it and use the C11 implementation everywhere.
> >
> > The lack of measured performance difference documentation is not a
> valid reason to remove the generic version!
> >
> > It would be reasonable to assume that x86 (and ThunderX) use the
> generic version for non-insignificant performance reasons.
> >
> > If there is no performance difference, I agree with this patch.
> Otherwise not.
> > This could be verified by providing the missing measurements.
> >
> 
> Surprisingly, the performance of the C11 version is better than the old
> generic
> version that had smp_mb.  That is because C11 code generates no locked
> prefixes.
> Gets speedup of upto 60%.
> 
> Between main (with rte_smp_mb) and the unified C11 version on the 32-
> core x86 machine:
> 
> Test	main (n=9)	unified C11 (n=9)	delta
> single push/pop	46.62 ±0.30	33.41 ±0.10	-28%
> empty pop	1.47 ±0.01	0.98 ±0.01	-33%
> 1 lcore, bulk 8	9.06 ±0.05	8.20 ±0.08	-10%
> 1 lcore, bulk 32	6.09 ±0.02	6.15 ±0.03	+1%
> 2 HT, bulk 8	42.05 ±0.31	39.24 ±0.52	-7%
> 2 HT, bulk 32	11.92 ±0.13	11.89 ±0.10	0
> 2 cores, bulk 8	78.90 ±0.60	72.96 ±1.11	-7%
> 2 cores, bulk 32	20.74 ±1.56	7.70 ±0.13	-63%
> 32 cores, bulk 8	6126 ±72	6121 ±89	0
> 32 cores, bulk 32	1953.9 ±2.9	1984.6 ±13.3	+1.6%

Thank you for testing, Stephen.

It clearly shows this patch deserves a big fat
Acked-by: Morten Brørup <mb@smartsharesystems.com>