From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: <dev@dpdk.org>, <bruce.richardson@intel.com>,
<konstantin.v.ananyev@yandex.ru>,
"Vipin Varghese" <vipin.varghese@amd.com>, <jerinj@marvell.com>,
"Maciej Czekaj" <mczekaj@marvell.com>
Subject: Re: [RFC 12/32] stack: always use C11 memory model implementation
Date: Sat, 1 Aug 2026 10:01:50 -0700 [thread overview]
Message-ID: <20260801100150.6e683948@phoenix.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F659AA@smartserver.smartshare.dk>
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%
next prev parent reply other threads:[~2026-08-01 17:01 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 17:53 [RFC 00/32] remove rte_smp barrier functions Stephen Hemminger
2026-07-29 17:53 ` [RFC 01/32] bpf: replace deprecated SMP barriers with C11 fences Stephen Hemminger
2026-07-30 8:48 ` Marat Khalili
2026-07-30 11:19 ` Marat Khalili
2026-07-30 12:51 ` Konstantin Ananyev
2026-07-30 9:23 ` Konstantin Ananyev
2026-07-29 17:53 ` [RFC 02/32] test: remove test for rte_smp_mb Stephen Hemminger
2026-07-30 7:25 ` Konstantin Ananyev
2026-07-29 17:53 ` [RFC 03/32] bus/vmbus: fix ring buffer ordering on weakly ordered CPUs Stephen Hemminger
2026-08-05 1:22 ` [EXTERNAL] " Long Li
2026-07-29 17:53 ` [RFC 04/32] bus/vmbus: fix missing acquire on receive ring index Stephen Hemminger
2026-08-05 1:23 ` [EXTERNAL] " Long Li
2026-07-29 17:53 ` [RFC 05/32] bus/vmbus: replace SMP barriers with C11 memory fences Stephen Hemminger
2026-07-29 17:53 ` [RFC 06/32] baseband: convert rte_smp_rmb to fence Stephen Hemminger
2026-07-29 17:54 ` [RFC 07/32] net/hinic: replace rte_smp_rmb Stephen Hemminger
2026-07-29 17:54 ` [RFC 08/32] net/intel: " Stephen Hemminger
2026-07-29 17:54 ` [RFC 09/32] crypto_caam_jr: " Stephen Hemminger
2026-08-06 6:10 ` Hemant Agrawal
2026-07-29 17:54 ` [RFC 10/32] net/virtio: replcae rte_smp_rmb Stephen Hemminger
2026-07-29 17:54 ` [RFC 11/32] net/thunderx: replace rte_smp_rmb Stephen Hemminger
2026-07-29 17:54 ` [RFC 12/32] stack: always use C11 memory model implementation Stephen Hemminger
2026-07-31 14:53 ` Morten Brørup
2026-08-01 15:25 ` Stephen Hemminger
2026-08-01 17:01 ` Stephen Hemminger [this message]
2026-08-02 6:33 ` Morten Brørup
2026-07-29 17:54 ` [RFC 13/32] ring: replace SMP read barrier with C11 acquire fence Stephen Hemminger
2026-07-30 8:16 ` Konstantin Ananyev
2026-07-31 14:47 ` Morten Brørup
2026-07-29 17:54 ` [RFC 14/32] crypto/virtio: update comment reference to rte_smp_rmb Stephen Hemminger
2026-07-29 17:54 ` [RFC 15/32] event/sw: fix unlinks in progress counter races Stephen Hemminger
2026-07-29 17:54 ` [RFC 16/32] event/sw: replace SMP barriers with C11 atomics Stephen Hemminger
2026-07-29 17:54 ` [RFC 17/32] eal/x86: move optimized fence out of SMP barrier Stephen Hemminger
2026-07-30 7:27 ` Konstantin Ananyev
2026-07-29 17:54 ` [RFC 18/32] common/octeontx: remove redundant barrier in mbox Stephen Hemminger
2026-07-29 17:54 ` [RFC 19/32] crypto/caam_jr: use IO barrier before job ring doorbell Stephen Hemminger
2026-08-06 6:11 ` Hemant Agrawal
2026-07-29 17:54 ` [RFC 20/32] crypto/octeontx: use IO barrier before doorbell Stephen Hemminger
2026-07-29 17:54 ` [RFC 21/32] mempool/octeontx: use IO barrier in pool destroy Stephen Hemminger
2026-07-29 17:54 ` [RFC 22/32] event/octeontx: replace deprecated SMP barriers Stephen Hemminger
2026-07-29 17:54 ` [RFC 23/32] event/dpaa2: replace deprecated barrier in selftest Stephen Hemminger
2026-08-06 6:11 ` Hemant Agrawal
2026-07-29 17:54 ` [RFC 24/32] event/dsw: replace SMP barriers with release fences Stephen Hemminger
2026-07-31 4:37 ` Mattias Rönnblom
2026-07-29 17:54 ` [RFC 25/32] event/opdl: replace SMP barriers with C11 atomics Stephen Hemminger
2026-07-29 17:54 ` [RFC 26/32] net/netvsc: replace SMP barrier in RNDIS response Stephen Hemminger
2026-07-29 17:54 ` [RFC 27/32] net/thunderx: replace deprecated SMP barriers Stephen Hemminger
2026-07-29 17:54 ` [RFC 28/32] net/virtio: replace deprecated barrier in avail index update Stephen Hemminger
2026-07-29 17:54 ` [RFC 29/32] eal: remove stale SMP barrier in rte_service Stephen Hemminger
2026-07-29 17:54 ` [RFC 30/32] eal: remove rte_smp_XX Stephen Hemminger
2026-07-29 17:54 ` [RFC 31/32] checkpatches: no longer warn about rte_smp_XX Stephen Hemminger
2026-07-29 17:54 ` [RFC 32/32] doc: update release notes about rte_smp_XX removal Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260801100150.6e683948@phoenix.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=mb@smartsharesystems.com \
--cc=mczekaj@marvell.com \
--cc=vipin.varghese@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).