All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	stable@dpdk.org, Harry van Haaren <harry.van.haaren@intel.com>
Subject: [RFC 15/32] event/sw: fix unlinks in progress counter races
Date: Wed, 29 Jul 2026 10:54:08 -0700	[thread overview]
Message-ID: <20260729175715.165120-16-stephen@networkplumber.org> (raw)
In-Reply-To: <20260729175715.165120-1-stephen@networkplumber.org>

The counter is written by both the application thread (increment on
unlink) and the scheduler (clear on ack) as a plain uint8_t. An
increment is lost if it lands between the scheduler's test and clear,
making rte_event_port_unlinks_in_progress() report completion before
the scheduler has seen the unlink. Nothing orders the scheduler's
later cq map reads against the counter test on a weakly ordered CPU
either.

Make the counter atomic: release fetch-add on unlink, acquire
exchange to clear. The exchange cannot lose a concurrent increment,
and the acquire guarantees the scheduler only acks unlinks whose cq
map update it can observe, replacing the full barrier in unlink.

Fixes: bd5ac24fea88 ("event/sw: implement unlinks in progress function")
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/event/sw/sw_evdev.c           |  8 +++++---
 drivers/event/sw/sw_evdev.h           |  2 +-
 drivers/event/sw/sw_evdev_scheduler.c | 13 ++++++++++---
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index 3ad82e94ac..bb6f50e03b 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -119,8 +119,9 @@ sw_port_unlink(struct rte_eventdev *dev, void *port, uint8_t queues[],
 		}
 	}
 
-	p->unlinks_in_progress += unlinked;
-	rte_smp_mb();
+	/* Pairs with the acquire exchange in the scheduler */
+	rte_atomic_fetch_add_explicit(&p->unlinks_in_progress, unlinked,
+				      rte_memory_order_release);
 
 	return unlinked;
 }
@@ -130,7 +131,8 @@ sw_port_unlinks_in_progress(struct rte_eventdev *dev, void *port)
 {
 	RTE_SET_USED(dev);
 	struct sw_port *p = port;
-	return p->unlinks_in_progress;
+	return rte_atomic_load_explicit(&p->unlinks_in_progress,
+					rte_memory_order_relaxed);
 }
 
 static int
diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index c159be21be..8b9118bf91 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -160,7 +160,7 @@ struct sw_port {
 	 * progress is read by the scheduler, no more events will be pushed to
 	 * the port - hence the scheduler core can just assign zero.
 	 */
-	uint8_t unlinks_in_progress;
+	RTE_ATOMIC(uint8_t) unlinks_in_progress;
 
 	int16_t is_directed; /** Takes from a single directed QID */
 	/**
diff --git a/drivers/event/sw/sw_evdev_scheduler.c b/drivers/event/sw/sw_evdev_scheduler.c
index a5fdcf301b..f4bce2cbb8 100644
--- a/drivers/event/sw/sw_evdev_scheduler.c
+++ b/drivers/event/sw/sw_evdev_scheduler.c
@@ -523,9 +523,16 @@ sw_event_schedule(struct rte_eventdev *dev)
 		do {
 			in_pkts = 0;
 			for (i = 0; i < sw->port_count; i++) {
-				/* ack the unlinks in progress as done */
-				if (sw->ports[i].unlinks_in_progress)
-					sw->ports[i].unlinks_in_progress = 0;
+				/* Ack the unlinks in progress as done. The
+				 * acquire exchange orders the cq map reads
+				 * below after the unlinker's map update.
+				 */
+				if (rte_atomic_load_explicit(
+						&sw->ports[i].unlinks_in_progress,
+						rte_memory_order_relaxed))
+					rte_atomic_exchange_explicit(
+						&sw->ports[i].unlinks_in_progress,
+						0, rte_memory_order_acquire);
 
 				if (sw->ports[i].is_directed)
 					in_pkts += sw_schedule_pull_port_dir(sw, i);
-- 
2.53.0


  parent reply	other threads:[~2026-07-29 17:58 UTC|newest]

Thread overview: 40+ 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-07-29 17:53 ` [RFC 04/32] bus/vmbus: fix missing acquire on receive ring index Stephen Hemminger
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-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-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-29 17:54 ` [RFC 14/32] crypto/virtio: update comment reference to rte_smp_rmb Stephen Hemminger
2026-07-29 17:54 ` Stephen Hemminger [this message]
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-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-07-29 17:54 ` [RFC 24/32] event/dsw: replace SMP barriers with release fences Stephen Hemminger
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=20260729175715.165120-16-stephen@networkplumber.org \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=stable@dpdk.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.