Netdev List
 help / color / mirror / Atom feed
From: Rongzheng Wang <testwrzwrz@gmail.com>
To: Stanislav Fomichev <sdf.kernel@gmail.com>
Cc: netdev@vger.kernel.org,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Magnus Karlsson <magnus.karlsson@intel.com>,
	Jason Xing <kerneljasonxing@gmail.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	stable@vger.kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 2/2] selftests/bpf: cover AF_XDP multi-buffer TX software checksum
Date: Sat, 31 Oct 2026 09:31:43 +0800	[thread overview]
Message-ID: <20261031013143.42509-1-testwrzwrz@gmail.com> (raw)
In-Reply-To: <auT51NbSPvKJwgiD@devvm16445.scu0.facebook.com>

> Any reason you're not reading the real value from
> /proc/sys/net/core/max_skb_frags ?

The test wants to exercise the maximum supported number of frames, but also
needs to run on every build. CONFIG_MAX_SKB_FRAGS ranges from 17 to 45, so
using the minimum (17, i.e. 18 frames) gives the largest bound that works
everywhere. af_xdp.rst documents the same limit:

  "For copy mode, the maximum supported number of frames in a packet is
   equal to CONFIG_MAX_SKB_FRAGS + 1."

xsk checks MAX_SKB_FRAGS directly (net/xdp/xsk.c), not
net.core.max_skb_frags. I also set net.core.max_skb_frags=4 and ran
xdp_metadata; it still passes, which confirms xsk does not consume that
sysctl. Reading it in this test would not tell us the xsk limit, and would
only reduce coverage if it is lowered.

CONFIG_MAX_SKB_FRAGS is compile-time and has no userspace interface, so 18
frames is the portable upper bound. That is why I used 17.

Thanks,
Rongzheng

      reply	other threads:[~2026-10-31  1:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30  2:32 [PATCH net v4 0/2] xsk: fix multi-buffer TX software checksum Rongzheng Wang
2026-10-30  2:32 ` [PATCH net v4 1/2] xsk: defer software checksum until the skb is complete Rongzheng Wang
2026-10-30  6:31   ` Jason Xing
2026-10-30  8:40     ` Rongzheng Wang
2026-10-30  9:15       ` Jason Xing
2026-10-30  9:46         ` Rongzheng Wang
2026-10-30 11:56           ` Maciej Fijalkowski
2026-10-30 12:24             ` Rongzheng Wang
2026-10-30  2:32 ` [PATCH net v4 2/2] selftests/bpf: cover AF_XDP multi-buffer TX software checksum Rongzheng Wang
2026-10-30 12:02   ` Maciej Fijalkowski
2026-10-30 20:12   ` Stanislav Fomichev
2026-10-31  1:31     ` Rongzheng Wang [this message]

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=20261031013143.42509-1-testwrzwrz@gmail.com \
    --to=testwrzwrz@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=hawk@kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdf.kernel@gmail.com \
    --cc=stable@vger.kernel.org \
    /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