From: Leon Hwang <leon.hwang@linux.dev>
To: Jakub Kicinski <kuba@kernel.org>, Leon Hwang <leon.huangfu@shopee.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [PATCH net-next] selftests/net: Add two xdp tests to xdp.py
Date: Thu, 2 Apr 2026 11:22:15 +0800 [thread overview]
Message-ID: <6c1d6987-ca73-40de-adab-bc6f9fce67f6@linux.dev> (raw)
In-Reply-To: <20260401132048.3a15601e@kernel.org>
On 2/4/26 04:20, Jakub Kicinski wrote:
> On Wed, 1 Apr 2026 13:27:46 +0800 Leon Hwang wrote:
[...]
>> +def _set_jumbo_mtu(cfg, mtu):
>> + ip(f"link set dev {cfg.ifname} mtu {mtu}")
>> + defer(ip, f"link set dev {cfg.ifname} mtu 1500")
>
> cfg records the original MTU, you can copy this line from here:
> https://elixir.bootlin.com/linux/v7.0-rc6/source/tools/testing/selftests/drivers/net/gro.py#L88
>
Sure, will use cfg.dev['mtu'] instead of hard code 1500.
>> +def _exec_cmd(cfg, obj, sec, ip_opts=""):
>> + return cmd(f"ip {ip_opts} link set dev {cfg.ifname} xdpdrv obj {obj} sec {sec}", shell=True, fail=False)
>
> We shouldn't need the shell=True where?
> Also it's probably cleaner to pass fail as optional argument here
> so that you can let this throw an exception in the cases we expect
> to succeed instead of having to check in the caller explicitly
>
Right, shell=True is unnecessary here. Will drop it.
Will pass fail as optional arg to let it fail if fail=True.
>> +def test_xdp_native_attach_sb_to_mb(cfg):
>> + obj = cfg.net_lib_dir / "xdp_dummy.bpf.o"
>> + mtu = 9000
>> +
>> + _set_jumbo_mtu(cfg, mtu)
>> +
>> + probe = _exec_cmd(cfg, obj, "xdp.frags")
>> + if probe.ret != 0:
>> + output = probe.stderr.strip() or probe.stdout.strip()
>> + raise KsftSkipEx(output or "device does not support multi-buffer XDP")
>
> May be simpler and cleaner to print the whole command separately:
>
> if probe.ret != 0:
> ksft_pr(probe)
> raise KsftSkipEx("device does not support multi-buffer XDP")
>
Ack.
>> + ip(f"link set dev {cfg.ifname} xdpdrv off")
>> +
>> + probe = _exec_cmd(cfg, obj, "xdp")
>> + if probe.ret == 0:
>> + ip(f"link set dev {cfg.ifname} xdpdrv off")
>> + raise KsftFailEx(f"driver unexpectedly allows non-multi-buffer XDP at MTU {mtu}")
>
> Hm, TBH I don't think this sb_to_mb case is adding any coverage.
> Let's just add the test case below?
>
Ok. Will drop this case.
>
>> +def test_xdp_native_update_mb_to_sb(cfg):
>> + obj = cfg.net_lib_dir / "xdp_dummy.bpf.o"
>> +
>> + _set_jumbo_mtu(cfg, 9000)
>> +
>> + attach = _exec_cmd(cfg, obj, "xdp.frags")
>> + if attach.ret != 0:
>> + output = attach.stderr.strip() or attach.stdout.strip()
>> + raise KsftSkipEx(output or "device does not support multi-buffer XDP")
>> +
>> + defer(ip, f"link set dev {cfg.ifname} xdpdrv off")
>> +
>> + update1 = _exec_cmd(cfg, obj, "xdp.frags", "-force")
>> + if update1.ret != 0:
>> + raise KsftFailEx("device fails to update multi-buffer XDP")
>> +
>> + update2 = _exec_cmd(cfg, obj, "xdp", "-force")
>> + if update2.ret == 0:
>> + raise KsftFailEx("device unexpectedly updates non-multi-buffer XDP")
From sashiko's review [1]:
On architectures with larger page sizes, such as 16KB or 64KB on ARM64 or
PowerPC, a 9000-byte packet can fit entirely within a single buffer. In
these environments, the driver might legally accept a non-frag XDP program,
which would lead to a false positive failure here.
WDYT?
[1]
https://sashiko.dev/#/patchset/20260401052746.314667-1-leon.huangfu%40shopee.com
Thanks,
Leon
next prev parent reply other threads:[~2026-04-02 3:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 5:27 [PATCH net-next] selftests/net: Add two xdp tests to xdp.py Leon Hwang
2026-04-01 20:20 ` Jakub Kicinski
2026-04-02 3:22 ` Leon Hwang [this message]
2026-04-02 14:35 ` Jakub Kicinski
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=6c1d6987-ca73-40de-adab-bc6f9fce67f6@linux.dev \
--to=leon.hwang@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=leon.huangfu@shopee.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.