Hi
On 10/18/25 1:09 PM, Maciej Fijalkowski wrote:
On Fri, Oct 17, 2025 at 11:27:26AM -0700, Alexei Starovoitov wrote:
On Thu, Oct 16, 2025 at 12:45 AM Bastien Curutchet (eBPF Foundation)
<[email protected]> wrote:
Hi all,
Now that the merge window is over, here's a respin of the previous
iteration rebased on the latest bpf-next_base. The bug triggering the
XDP_ADJUST_TAIL_SHRINK_MULTI_BUFF failure when CONFIG_DEBUG_VM is
enabled hasn't been fixed yet so I've moved the test to the flaky
table.
The test_xsk.sh script covers many AF_XDP use cases. The tests it runs
are defined in xksxceiver.c. Since this script is used to test real
hardware, the goal here is to leave it as it is, and only integrate the
tests that run on veth peers into the test_progs framework.
Some tests are flaky so they can't be integrated in the CI as they are.
I think that fixing their flakyness would require a significant amount of
work. So, as first step, I've excluded them from the list of tests
migrated to the CI (cf PATCH 14). If these tests get fixed at some
point, integrating them into the CI will be straightforward.
PATCH 1 extracts test_xsk[.c/.h] from xskxceiver[.c/.h] to make the
tests available to test_progs.
PATCH 2 to 7 fix small issues in the current test
PATCH 8 to 13 handle all errors to release resources instead of calling
exit() when any error occurs.
PATCH 14 isolates some flaky tests
PATCH 15 integrate the non-flaky tests to the test_progs framework
Looks good, but why does it take so long to run?
time ./test_progs -t xsk
Summary: 2/66 PASSED, 0 SKIPPED, 0 FAILED
real 0m29.031s
user 0m4.414s
sys 0m20.893s
That's a big addition to overall test_progs time.
Could you reduce it to a couple seconds?
it's because veth pair is setup per each test case from what i recall when
i was pointing this out during review. it does not scale. it would be
better to have veth created once for whole test suite. HTH.
The initial test_xsk.sh was already quite long, the test migration
hasn't affected its execution time on my side.
I've tried setting up the veth peers once for all the subtests, as
suggested by Maciej; this results in about a 35% speed gain on my setup,
but unfortunately, it’s still not enough to bring it down to a couple of
seconds.
I'll investigate it further.
Best regards,
Bastien
