From: Tianyi Gao <tianyi@cloudflare.com>
To: netdev@vger.kernel.org
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
kuba@kernel.org, pabeni@redhat.com, toke@redhat.com,
lorenzo@kernel.org, horms@kernel.org, bpf@vger.kernel.org,
shuah@kernel.org, hawk@kernel.org, kernel-team@cloudflare.com,
ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
sdf@fomichev.me, linux-kselftest@vger.kernel.org,
Tianyi Gao <tianyi@cloudflare.com>
Subject: [PATCH net-next v2 0/3] veth: link RX queues to their NAPI instances
Date: Wed, 11 Nov 2026 01:59:19 +0000 [thread overview]
Message-ID: <20261111015922.67745-1-tianyi@cloudflare.com> (raw)
veth does not link its RX queues to their NAPI instances. queue-get
therefore reports no napi-id for them. napi-get lists the NAPI instances
of a veth, and their thread PIDs when NAPI is threaded. It does not show
which RX queue each instance polls. Userspace cannot tell which NAPI
thread to pin for a given queue, or which NAPI to change with napi-set.
There is also no way to busy poll an AF_XDP socket bound to a veth
queue. xsk_bind() takes the socket's NAPI ID from the RX queue, and a
veth RX queue has none.
Patch 1 is a cleanup to ease review of patch 2. veth_enable_xdp_range()
adds the NAPI instances only to pass their napi_id to
xdp_rxq_info_reg(), which no longer uses it. Patch 1 moves
netif_napi_add() into the loop that enables the NAPI instances. It also
removes the arguments and wrappers that came with adding the NAPI
instances in two places.
Patch 2 calls netif_queue_set_napi() in veth_napi_enable_range(), after
napi_enable(). In veth_napi_del_range(), it clears the link with NULL
before napi_disable().
Patch 3 adds RX queue NAPI link checks to veth.sh. The napi-id of every
RX queue must match a NAPI instance of the device. The queues must be
linked only while NAPI is enabled. The checks run with GRO on and with
XDP attached, and across RX channel changes and link down/up.
---
Changes in v2:
- Rebase on net-next. Patch 3 no longer applied after commit
c1f04ea0aa0f ("selftests: net: check veth carrier after changing
channel counts"). The conflict is in context only. No code change.
- v1: https://lore.kernel.org/all/20261105143356.17062-1-tianyi@cloudflare.com/
Tianyi Gao (3):
veth: refactor NAPI enable paths
veth: link RX queues to their NAPI instances
selftests: net: veth: test RX queue NAPI links
drivers/net/veth.c | 83 ++++++++---------------------
tools/testing/selftests/net/veth.sh | 79 ++++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 63 deletions(-)
base-commit: 79ee9e6768721f337952e9b3edd14cedbbc03030
--
2.56.0
next reply other threads:[~2026-11-11 1:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 1:59 Tianyi Gao [this message]
2026-11-11 1:59 ` [PATCH net-next v2 1/3] veth: refactor NAPI enable paths Tianyi Gao
2026-11-11 1:59 ` [PATCH net-next v2 2/3] veth: link RX queues to their NAPI instances Tianyi Gao
2026-11-11 1:59 ` [PATCH net-next v2 3/3] selftests: net: veth: test RX queue NAPI links Tianyi Gao
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=20261111015922.67745-1-tianyi@cloudflare.com \
--to=tianyi@cloudflare.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=toke@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