Re: [PATCH net v4 2/2] selftests/bpf: cover AF_XDP multi-buffer TX software checksum

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 10/31, Rongzheng Wang wrote:
> > 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.

Sure, people can set max_skb_frags to < CONFIG_MAX_SKB_FRAGS, but I
don't think we are gonna do it on our runners. So for the purpose of
this test we can essentially assume CONFIG_MAX_SKB_FRAGS ==
max_skb_frags.

I'm just trying to understand whether on the builds that have
CONFIG_MAX_SKB_FRAGS > 17 we want to exercise all CONFIG_MAX_SKB_FRAGS
or we are ok wit just 17.. But we probably aren't going to bump
CONFIG_MAX_SKB_FRAGS on upstream kernels anytime soon..

Acked-by: Stanislav Fomichev <sdf@fomichev.me>