Re: [PATCH net-next] veth: clear rx queue hint in veth_xmit

[Paolo Abeni <pabeni@redhat.com>]

On 10/13/26 10:14, Toshiaki Makita wrote:
> 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)

I think the above is correct; I'll update the tag accordingly

For the same reason I agree this is net-next material.

/P