Netdev List
 help / color / mirror / Atom feed
From: Toshiaki Makita <toshiaki.makita1@gmail.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>, netdev@vger.kernel.org
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] veth: clear rx queue hint in veth_xmit
Date: Tue, 13 Oct 2026 17:14:00 +0900	[thread overview]
Message-ID: <65a3e29a-24e0-47b3-a189-903b1a33c336@gmail.com> (raw)
In-Reply-To: <20261009040412.14571-1-jiayuan.chen@linux.dev>

On 2026/10/09 13:04, Jiayuan Chen wrote:
> With more tx queues on one end of a veth pair than rx queues on the
> other, and RPS or generic XDP enabled on the receiving end, we get:
> 
>      veth1 received packet on queue 2, but number of RX queues is 2
>      WARNING: net/core/dev.c:5212 at get_rps_cpu+0x560/0x1360
>      Call Trace:
>       <TASK>
>       netif_rx_internal+0x1af/0x4c0
>       __netif_rx+0x99/0x350
>       veth_xmit+0x713/0xca0
>       dev_hard_start_xmit+0x166/0x5f0
>       __dev_queue_xmit+0x1797/0x42d0
>       ip_finish_output2+0xa34/0x1f40
>       __ip_finish_output+0x510/0x7e0
>       ip_finish_output+0x2f/0x320
>       ip_output+0x17a/0x3f0
>       ip_send_skb+0x1bc/0x220
>       ......
> 
> Easy to hit with "ethtool -L veth0 tx 4", "ethtool -L veth1 rx 2",
> rps_cpus set on veth1 and a few flows sent over the pair [1].
> 
> veth_xmit() uses skb->queue_mapping to pick the peer rq, but never
> clears it before veth_forward_skb(), so the rx side still sees the tx
> queue index. Everything on the rx side that goes through
> skb_get_rx_queue(), like get_rps_cpu() and netif_get_rxqueue() for
> generic XDP, takes it as a recorded rx queue and warns once it is out
> of range.
> 
> Clear it before handing the skb to the peer:
> 
> - It is the tx queue index of this device, it says nothing about the
>    rx queue of the peer.
> 
> - The two sides don't even agree on the encoding. The tx side stores
>    the index as is, the rx side stores index + 1 so that 0 can mean
>    "not recorded". So tx queue k is read back as rx queue k - 1, and
>    tx queue 0 as "not recorded".
> 
> - Commit 710ad98c363a ("veth: Do not record rx queue hint in
>    veth_xmit") already decided that veth should not pass any queue
>    hint to the peer. There is no tx->rx queue mapping to preserve, so
>    nothing is lost by clearing it.
> 
> On NETDEV_TX_BUSY the skb goes back to the qdisc, which looks up the
> txq from skb->queue_mapping to decide when to retry, so restore it
> there, next to the existing __skb_push().
> 
> [1]: https://lore.kernel.org/netdev/156834bb-8e40-496e-9443-9d515fa18eab@linux.dev/
> 
> Fixes: 710ad98c363a ("veth: Do not record rx queue hint in veth_xmit")

I guess the splat can happen before this commit.
I'm not very sure but probably it has been possible since after 76ff5cc91935
(with ip link add numtxqueues & numrxqueues, instead of ethtool -L)

> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

I agree with the patch itself.

Reviewed-by: Toshiaki Makita <toshiaki.makita1@gmail.com>


  parent reply	other threads:[~2026-10-13  8:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  4:04 [PATCH net-next] veth: clear rx queue hint in veth_xmit Jiayuan Chen
2026-10-09  6:52 ` Björn Töpel
2026-10-13  8:14 ` Toshiaki Makita [this message]
2026-10-13 12:58 ` Lorenzo Bianconi

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=65a3e29a-24e0-47b3-a189-903b1a33c336@gmail.com \
    --to=toshiaki.makita1@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiayuan.chen@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --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