dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
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%


  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).