From: Martin KaFai Lau <martin.lau@linux.dev>
To: "Alexis Lothoré (eBPF Foundation)" <alexis.lothore@bootlin.com>,
"Lorenzo Bianconi" <lorenzo@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
Shuah Khan <shuah@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
ebpf@linuxfoundation.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] selftests/bpf: convert test_xdp_features.sh to test_progs
Date: Fri, 13 Sep 2024 15:22:00 -0700 [thread overview]
Message-ID: <64df8d41-6cfb-45a9-8337-5cc04daedb60@linux.dev> (raw)
In-Reply-To: <20240910-convert_xdp_tests-v2-1-a46367c9d038@bootlin.com>
On 9/10/24 11:10 AM, Alexis Lothoré (eBPF Foundation) wrote:
> test_xdp_features.sh is a shell script allowing to test that xdp features
> advertised by an interface are indeed delivered. The test works by starting
> two instance of the same program, both attaching specific xdp programs to
> each side of a veth link, and then make those programs manage packets and
> collect stats to check whether tested XDP feature is indeed delivered or
> not. However this test is not integrated in test_progs framework and so can
> not run automatically in CI.
>
> Rewrite test_xdp_features to integrate it in test_progs so it can run
> automatically in CI. The main changes brought by the rewrite are the
> following:
> - instead of running to separated processes (each one managing either the
> tester veth or the DUT vet), run a single process
> - slightly change testing direction (v0 is the tester in local namespace,
> v1 is the Device Under Test in remote namespace)
> - group all tests previously managed by test_xdp_features as subtests (one
> per tested XDP feature). As a consequence, run only once some steps
> instead of once per subtest (eg: starting/stopping the udp server). On
> the contrary, make sure that each subtest properly cleans up its state
> (ie detach xdp programs, reset test stats, etc)
> - since there is now a single process, get rid of the "control" tcp channel
> used to configure DUT. Configuring the DUT now only consists in switching
> to DUT network namespace and run the relevant commands
> - since there is no more control channel, get rid of TLVs, keep only the
> CMD_ECHO packet type, and set it as a magic
> - simplify network setup: use only ipv6 instead of both ipv4 and ipv6,
> force static neighbours instead of waiting for autoconfiguration, do not
> force gro (fetch xdp features only once xdp programs are loaded instead)
>
> The existing XDP programs are reused, with some minor changes:
> - tester and dut stats maps are converted to global variables for easier
> usage
> - programs do not use TLV struct anymore but the magic replacing the echo
> command
> - avoid to accidentally make tests pass: drop packets instead of forwarding
> them to userspace when they do not match the expected payload
> - make sure to perform host <-> network endianness conversion on constants
> rather than packet parts
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> Changes in v2:
> - fix endianness management in userspace packet parsing (call htonl on
> constant rather than packet part)
>
> The xdp_features rewrite has been tested in a x86_64 qemu environment on my
> machine and in CI. In my environment, the test takes a bit less than 2s to
> execute.
>
> # ./test_progs -a xdp_features
> #561/1 xdp_features/XDP_PASS:OK
> #561/2 xdp_features/XDP_DROP:OK
> #561/3 xdp_features/XDP_ABORTED:OK
> #561/4 xdp_features/XDP_TX:OK
> #561/5 xdp_features/XDP_REDIRECT:OK
> #561/6 xdp_features/XDP_NDO_XMIT:OK
> #561 xdp_features:OK
> Summary: 1/6 PASSED, 0 SKIPPED, 0 FAILED
> ---
> tools/testing/selftests/bpf/.gitignore | 1 -
> tools/testing/selftests/bpf/Makefile | 10 +-
> .../selftests/bpf/prog_tests/xdp_features.c | 446 +++++++++++++
> tools/testing/selftests/bpf/progs/xdp_features.c | 49 +-
> tools/testing/selftests/bpf/test_xdp_features.sh | 107 ---
> tools/testing/selftests/bpf/xdp_features.c | 718 ---------------------
From the initial commit message of xdp_features.c, its primary usage is to test
a physical network device that supports a certain XDP features.
iiuc, test_xdp_features.sh only uses the veth and veth will also be the only
device tested after moving to prog_tests/xdp_features.c? It is a reasonable
addition to test_progs for an end-to-end xdp test by using veth. However,
test_progs will not be able to test the physical network device.
Lorenzo, is the xdp_features.c still used for device testing?
next prev parent reply other threads:[~2024-09-13 22:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 18:10 [PATCH bpf-next v2] selftests/bpf: convert test_xdp_features.sh to test_progs Alexis Lothoré (eBPF Foundation)
2024-09-11 14:18 ` Simon Horman
2024-09-12 20:17 ` Alexis Lothoré
2024-09-13 7:26 ` Simon Horman
2024-09-13 22:22 ` Martin KaFai Lau [this message]
2024-09-14 9:25 ` Lorenzo Bianconi
2024-09-14 13:38 ` Jakub Kicinski
2024-09-22 10:04 ` Alexis Lothoré
2024-09-25 1:37 ` Martin KaFai Lau
2024-09-25 20:01 ` Martin KaFai Lau
2024-09-26 10:14 ` Alexis Lothoré
2024-10-04 4:44 ` Martin KaFai Lau
2024-10-04 6:23 ` Alexis Lothoré
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=64df8d41-6cfb-45a9-8337-5cc04daedb60@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexis.lothore@bootlin.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ebpf@linuxfoundation.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=yonghong.song@linux.dev \
/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