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 08:25:14 -0700 [thread overview]
Message-ID: <20260801082514.4fd2c724@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.
>
The reason is that smp_mb's need to go away.
The other option is revise to replace with thread fence, at which
point it becomes the same as generic code.
next prev parent reply other threads:[~2026-08-01 15:25 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 [this message]
2026-08-01 17:01 ` Stephen Hemminger
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=20260801082514.4fd2c724@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