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

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 [off-list ref] wrote:

quoted

+TO: x86 maintainers, ThunderX maintainers

quoted

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!

quoted

It would be reasonable to assume that x86 (and ThunderX) use the

generic version for non-insignificant performance reasons.

quoted

If there is no performance difference, I agree with this patch.

Otherwise not.

quoted

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 <redacted>