From: sashiko-bot@kernel.org
To: "Simon Schippers" <simon.schippers@tu-dortmund.de>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net 1/2] veth: wake a stopped peer txq beyond real_num_tx_queues
Date: Sat, 14 Nov 2026 10:47:21 +0000 [thread overview]
Message-ID: <sashiko-outbox-214363@kernel.org> (raw)
In-Reply-To: <20261113104648.225983-2-simon.schippers@tu-dortmund.de>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] veth: Fixes trailer cites dc82a33297fc instead of 08f566e8f83b
--
commit 4511ff49371a3a9f93211f5b51b7a6404ecb1f22
Author: Simon Schippers <simon.schippers@tu-dortmund.de>
> veth: wake a stopped peer txq beyond real_num_tx_queues
>
> Since commit dc82a33297fc ("veth: apply qdisc backpressure on full
> ptr_ring to reduce TX drops"), only the peer's veth_poll() wakes a txq
> that veth_xmit() stopped on a full ptr_ring. veth_poll() skips txqs at
> or above the peer's real_num_tx_queues.
>
> If the peer shrinks its TX channels while such a txq is stopped, nothing
> wakes it. netif_set_real_num_tx_queues() keeps its state, so once the
> channels are grown back, its first skb is requeued forever. With a single
> root qdisc this blocks all transmission of the device.
>
> Look the txq up below num_tx_queues instead. Waking a txq that is not in
> use is harmless.
>
> Reproduced in virtme-ng with a UDP flood from veth0 into veth1, which has
> GRO, while switching veth0 between one and two TX channels: without this
> patch veth0 stopped transmitting within 11 cycles in 3 of 3 runs, with
> it veth0 kept transmitting through 30 cycles in 3 of 3 runs.
>
> Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
[Severity: Low]
Should the Fixes: tag reference 08f566e8f83b ("veth: fix OOB txq access
in veth_poll() with asymmetric queue counts") instead?
Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to
reduce TX drops") looked up peer_txq unconditionally via
netdev_get_tx_queue(peer_dev, queue_idx). The queue_idx <
peer_dev->real_num_tx_queues check that skips txqs above
real_num_tx_queues in veth_poll() was introduced in 08f566e8f83b ("veth:
fix OOB txq access in veth_poll() with asymmetric queue counts").
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261113104648.225983-1-simon.schippers@tu-dortmund.de?part=1
next prev parent reply other threads:[~2026-11-14 10:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 10:46 [PATCH net 0/2] veth: fix txqs that are never woken after backpressure Simon Schippers
2026-11-13 10:46 ` [PATCH net 1/2] veth: wake a stopped peer txq beyond real_num_tx_queues Simon Schippers
2026-11-14 10:47 ` sashiko-bot [this message]
2026-11-13 10:46 ` [PATCH net 2/2] veth: wake the peer txq when deleting NAPI Simon Schippers
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=sashiko-outbox-214363@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=simon.schippers@tu-dortmund.de \
/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