From: John Macias <dencity7@gmail.com>
To: netdev@vger.kernel.org
Cc: andrew@lunn.ch, olteanv@gmail.com, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net] net: dsa: clear the conduit RX queue on user port receive
Date: Sun, 25 Oct 2026 00:22:03 -0700 [thread overview]
Message-ID: <20261025072203.1519561-1-dencity7@gmail.com> (raw)
A multi-queue conduit records its RX queue in skb->queue_mapping with
skb_record_rx_queue(), as stmmac, mtk_eth_soc, fec and dpaa2 do.
dsa_switch_rcv() passes the skb to the user port with that value
unchanged, but user ports have a single RX queue. For a packet that
arrived on conduit queue 1 or above, get_rps_cpu() finds the index past
the user port's real_num_rx_queues and returns without steering. The
WARN_ONCE() there stays silent because the port has only one queue. As
a result, rps_cpus on a user port takes effect only for packets that
arrived on conduit queue 0.
Clear the queue mapping when the skb is handed to the user port. TX
queue selection is unaffected: the user port's own netdev_pick_tx() sets
queue_mapping again before the conduit transmits.
Found on an IPQ8074 board (OpenWrt, Linux 6.18, conduit with four RX
rings): with rps_cpus set on the LAN and WAN user ports,
/proc/net/softnet_stat showed no RPS for traffic hashed to conduit
rings 1-3. With this change, that traffic is steered to the configured
CPUs.
Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support")
Assisted-by: LLM
Signed-off-by: John Macias <dencity7@gmail.com>
---
The Fixes tag points at the commit that added the DSA receive path. The
problem shows up once RPS is used on a user port, since get_rps_cpu()
checks the recorded queue against the port's own queue count.
This was found and fixed with an AI coding assistant (Claude, from
Anthropic). It traced the missing RPS to the stale queue_mapping, wrote
the change and this changelog, and ran the tests on my hardware. I have
reviewed the change.
Testing: the same change on OpenWrt's Linux 6.18 on a Netgear RAX120 v1
(IPQ8074, out-of-tree qca_edma conduit with four RX rings, RSS over all
four). Before, received_rps stayed at 0 on every CPU over 8 runs of
bidirectional UDP with rps_cpus set on lan1 and wan. After, it rises on
the configured CPUs for traffic from rings 1-3. On this tree (net,
7076f684d) the change is build-tested only (x86_64 defconfig with
NET_DSA, W=1, WERROR). I have not tested it with a mainline conduit
driver.
net/dsa/tag.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/dsa/tag.c b/net/dsa/tag.c
index 6a5aa7fc3..ecd4d8669 100644
--- a/net/dsa/tag.c
+++ b/net/dsa/tag.c
@@ -115,6 +115,12 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev,
skb = nskb;
}
+ /* The conduit's RX queue index means nothing on the user port, which
+ * has a single RX queue, and get_rps_cpu() skips RPS when the index
+ * is out of range.
+ */
+ skb_set_queue_mapping(skb, 0);
+
dev_sw_netstats_rx_add(skb->dev, skb->len + ETH_HLEN);
if (dsa_skb_defer_rx_timestamp(p, skb))
--
2.47.3
next reply other threads:[~2026-10-25 7:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 7:22 John Macias [this message]
2026-10-26 7:24 ` netdev-bot+sashiko
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=20261025072203.1519561-1-dencity7@gmail.com \
--to=dencity7@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.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
all inboxes | Powered by JetHome®