From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: <netdev-bot+sashiko@kernel.org>
Cc: <netdev@vger.kernel.org>, <bpf@vger.kernel.org>,
<magnus.karlsson@intel.com>, <stfomichev@gmail.com>,
<kuba@kernel.org>, <pabeni@redhat.com>,
<tushar.vyavahare@intel.com>, <kerneljasonxing@gmail.com>,
<bjorn@kernel.org>
Subject: Re: [PATCH v3 net-next 02/15] selftests: xsk: size the TX UMEM in HW_SW_MAX_RING_SIZE
Date: Sat, 17 Oct 2026 16:40:38 +0200 [thread overview]
Message-ID: <atOI5qcfc1TxumvI@boxer> (raw)
In-Reply-To: <179220636394.434549.14546514468412075500@kernel.org>
On Sat, Oct 17, 2026 at 03:06:03AM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] In testapp_hw_sw_max_ring_size()
> (tools/testing/selftests/bpf/prog_tests/test_xsk.c), the patch gives…
>
> --
>
> selftests: xsk: size the TX UMEM in HW_SW_MAX_RING_SIZE
>
> In testapp_hw_sw_max_ring_size(), this patch gives the TX UMEM the same
> 8k frames, fill ring and completion ring as the RX UMEM. In two-interface
> mode the TX UMEM has only 1k frames, so the 2k batch stalls in
> __send_pkts(). The patch prepares for removing the single-interface mode
> in the next patch.
>
> > diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> > index 2a13628740924..16fe32e5afc06 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> > @@ -2513,6 +2513,9 @@ int testapp_hw_sw_max_ring_size(struct test_spec *test)
> > test->ifobj_rx->xsk->umem->num_frames = max_descs;
> > test->ifobj_rx->xsk->umem->fill_size = max_descs;
> > test->ifobj_rx->xsk->umem->comp_size = max_descs;
> > + test->ifobj_tx->xsk->umem->num_frames = max_descs;
> > + test->ifobj_tx->xsk->umem->fill_size = max_descs;
> > + test->ifobj_tx->xsk->umem->comp_size = max_descs;
>
> [Severity: Medium]
> Does the second step still stall on NICs that report a tx_max_pending of
> 8200 or more?
>
> max_descs is fixed at 4 * XSK_RING_PROD__DEFAULT_NUM_DESCS, which is 8192.
> The step-2 batch later in testapp_hw_sw_max_ring_size() still comes from
> the maximum the driver reports:
>
> test->ifobj_tx->xsk->batch_size = test->ifobj_tx->ring.tx_max_pending - 8;
>
> Here is the in-flight limit check in __send_pkts():
>
> if (pkts_in_flight >= (int)((umem_size(umem) - xsk->batch_size * buffer_len) /
> buffer_len) && !test_timeout) {
>
> With batch_size == 8192 the limit is 0. With batch_size > 8192 the u64
> subtraction wraps, and the truncated int is 8192 - batch_size, which is
> negative. In both cases TX only kicks and returns TEST_CONTINUE.
>
> Even if that check passed, xsk_ring_prod__reserve(&xsk->tx, batch_size,
> ...) can never reserve more than the 8192 slots of the TX ring. This is
> because xsk_configure_socket() sets cfg.tx_size = umem->comp_size.
>
> Some hardware that supports AF_XDP reports larger maximums:
>
> - octeontx2: otx2_get_ringparam() reports tx_max_pending =
> Q_COUNT(Q_SIZE_MAX), which is 1048576. The batch is 1048568 and the
> limit is -1040376.
> - hns3: reports HNS3_RING_MAX_PENDING, which is 32760. The batch is 32752
> and the limit is -24560.
>
> ice (8160) and mlx5 (8192) fit within the limit.
>
> On the larger NICs, TX never sends and RX times out. That seems to be the
> same failure the commit message describes:
>
> "the in-flight limit in __send_pkts() turns negative for a 2k batch,
> so TX never sends and RX times out, and the second batch would not fit
> in the TX ring anyway."
>
> At the end of the series, tools/testing/selftests/net/lib/xsk/test_xsk.c
> still uses the fixed 8192 and xsk_get_cap(test, tx_max_pending) - 8. Once
> the single-interface mode is gone, two-interface mode is the only one
> left, so this case would keep failing on those NICs.
>
> A 1M-frame UMEM would need 4 GiB. Could the step-2 batch be clamped to
> the software ring instead, for example min(tx_max_pending, max_descs) - 8?
I have sent v4 already which addresses this:
batch_size = min(tx_max_pending, max_descs) - 8;
test->ifobj_tx->xsk->batch_size = batch_size;
test->ifobj_rx->xsk->batch_size = batch_size;
>
> [ ... ]
>
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261014184539.774708-1-maciej.fijalkowski%40intel.com
next prev parent reply other threads:[~2026-10-17 14:40 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 18:45 [PATCH v3 net-next 00/15] selftests: net: migrate AF_XDP test suite over to net Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 01/15] selftests: xsk: factor endpoint work out of pthread wrappers Maciej Fijalkowski
2026-10-15 8:14 ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 02/15] selftests: xsk: size the TX UMEM in HW_SW_MAX_RING_SIZE Maciej Fijalkowski
2026-10-15 8:15 ` Björn Töpel
2026-10-15 18:46 ` sashiko-bot
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-17 14:40 ` Maciej Fijalkowski [this message]
2026-10-14 18:45 ` [PATCH v3 net-next 03/15] selftests: xsk: drop the single-interface loopback mode Maciej Fijalkowski
2026-10-15 8:17 ` Björn Töpel
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-17 14:50 ` Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 04/15] selftests/bpf: drop the test_progs AF_XDP wrapper Maciej Fijalkowski
2026-10-15 8:18 ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 05/15] selftests: net: add a generic rule for BPF skeletons Maciej Fijalkowski
2026-10-15 8:20 ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 06/15] selftests: xsk: move the AF_XDP test suite to selftests/net Maciej Fijalkowski
2026-10-15 8:22 ` Björn Töpel
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-17 15:31 ` Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 07/15] selftests: xsk: collect interface capabilities in struct xsk_caps Maciej Fijalkowski
2026-10-15 8:27 ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 08/15] selftests: xsk: split xskxceiver main() into setup, run and cleanup Maciej Fijalkowski
2026-10-15 8:29 ` Björn Töpel
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-14 18:45 ` [PATCH v3 net-next 09/15] selftests: xsk: run one test case per xskxceiver invocation Maciej Fijalkowski
2026-10-15 8:34 ` Björn Töpel
2026-10-15 18:46 ` sashiko-bot
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-17 16:04 ` Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 10/15] selftests: xsk: run the RX and TX endpoints in separate processes Maciej Fijalkowski
2026-10-15 9:04 ` Björn Töpel
2026-10-14 18:45 ` [PATCH v3 net-next 11/15] selftests: xsk: add a hardware mode to xskxceiver Maciej Fijalkowski
2026-10-15 9:42 ` Björn Töpel
2026-10-15 10:55 ` Maciej Fijalkowski
2026-10-15 16:03 ` Björn Töpel
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-17 17:40 ` Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 12/15] selftests: xsk: pass non-test traffic to the stack in hardware mode Maciej Fijalkowski
2026-10-15 10:05 ` Björn Töpel
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-14 18:45 ` [PATCH v3 net-next 13/15] selftests: xsk: list the hardware test cases Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 14/15] selftests: drv-net: test AF_XDP zero-copy with an SKB peer Maciej Fijalkowski
2026-10-15 10:29 ` Björn Töpel
2026-10-15 12:52 ` Maciej Fijalkowski
2026-10-15 18:46 ` sashiko-bot
2026-10-17 3:06 ` netdev-bot+sashiko
2026-10-17 18:50 ` Maciej Fijalkowski
2026-10-14 18:45 ` [PATCH v3 net-next 15/15] selftests: xsk: document generic and hardware endpoint runs Maciej Fijalkowski
2026-10-17 3:06 ` 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=atOI5qcfc1TxumvI@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stfomichev@gmail.com \
--cc=tushar.vyavahare@intel.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