From: Orgad Shaneh <orgads@gmail.com>
To: dev@dpdk.org
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Wei Hu <weh@microsoft.com>, Long Li <longli@kernel.org>,
Aditya Garg <gargaditya@microsoft.com>
Subject: [PATCH] net/mana: do not block Rx interrupt calls during a reset
Date: Tue, 10 Nov 2026 09:42:43 +0000 [thread overview]
Message-ID: <20261110094243.151321-1-orgads@gmail.com> (raw)
In-Reply-To: <20261109142127.7a54ee80@phoenix.local>
Rx interrupt enable and disable wait for reset_ops_lock and then
return -EBUSY if a reset is in progress. The reset thread holds that
lock across the teardown (mana_dev_stop(), the RESET_ENTER request
to secondary processes, mana_dev_close()) and across the re-probe,
and each request to the secondaries may take up to
MANA_MP_REQ_TIMEOUT_SEC. An lcore that calls rx_intr_enable or
rx_intr_disable during one of those steps blocks for that long,
only to get -EBUSY.
Retry the trylock while the device is active, and return -EBUSY as
soon as it is not. Outside a reset the lock is held only by another
queue's doorbell write or event read, so the wait stays short; once
a reset has started, the caller returns at once.
Suggested-by: Wei Hu <weh@microsoft.com>
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
---
Applies on next-net for-main, on top of efa36b47334d ("net/mana: fix
Rx interrupt enable failing on lock contention"). Squash it into that
commit if you prefer.
Follow-up to Wei's review and the AI review note:
https://inbox.dpdk.org/dev/20261109142127.7a54ee80@phoenix.local/
Builds with meson -Dwerror=true (gcc 14, rdma-core 56). With no reset
in progress the calls take the lock and run the same code as before,
so the Azure results in efa36b47334d still apply. A MANA reset cannot
be triggered on demand on Azure, so the reset path is untested.
The burst_state gate stays a possible follow-up for main.
drivers/net/mana/mana.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/mana/mana.c b/drivers/net/mana/mana.c
index f624cde6b9..eea9dac253 100644
--- a/drivers/net/mana/mana.c
+++ b/drivers/net/mana/mana.c
@@ -451,14 +451,21 @@ mana_reset_trylock(struct mana_priv *priv)
}
/*
- * Like mana_reset_trylock(), but wait for the lock. Used by Rx interrupt
- * enable/disable, which every queue calls on each sleep and wakeup: they
- * must not fail just because another queue holds the lock for a moment.
+ * Like mana_reset_trylock(), but wait while another queue holds the lock.
+ * Used by Rx interrupt enable/disable, which every queue calls on each
+ * sleep and wakeup: they must not fail just because another queue holds
+ * the lock for a moment. Once a reset has started, fail at once instead
+ * of waiting for its teardown or re-probe step.
*/
static int
mana_reset_lock(struct mana_priv *priv)
{
- pthread_mutex_lock(&priv->reset_ops_lock);
+ while (pthread_mutex_trylock(&priv->reset_ops_lock)) {
+ if (rte_atomic_load_explicit(&priv->dev_state,
+ rte_memory_order_relaxed) != MANA_DEV_ACTIVE)
+ return -EBUSY;
+ rte_pause();
+ }
if (rte_atomic_load_explicit(&priv->dev_state,
rte_memory_order_acquire) != MANA_DEV_ACTIVE) {
--
2.52.0
next prev parent reply other threads:[~2026-11-10 13:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 7:08 [PATCH 1/2] net/mana: fix Rx interrupt vector beyond device count Orgad Shaneh
2026-11-02 7:08 ` [PATCH 2/2] net/mana: fix Rx interrupt enable failing on lock contention Orgad Shaneh
2026-11-02 8:12 ` Stephen Hemminger
2026-11-02 8:27 ` Orgad Shaneh
2026-11-09 11:25 ` [EXTERNAL] " Wei Hu
2026-11-09 14:02 ` Orgad Shaneh
2026-11-10 14:33 ` Stephen Hemminger
2026-11-09 22:21 ` Stephen Hemminger
2026-11-10 9:42 ` Orgad Shaneh [this message]
2026-11-10 14:47 ` [PATCH] net/mana: do not block Rx interrupt calls during a reset Stephen Hemminger
2026-11-10 15:13 ` [PATCH v2] " Orgad Shaneh
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=20261110094243.151321-1-orgads@gmail.com \
--to=orgads@gmail.com \
--cc=dev@dpdk.org \
--cc=gargaditya@microsoft.com \
--cc=longli@kernel.org \
--cc=stephen@networkplumber.org \
--cc=weh@microsoft.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 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.