Re: [PATCH bpf-next v5 00/15] selftests/bpf: Integrate test_xsk.c to test_progs framework

[Bastien Curutchet <bastien.curutchet@bootlin.com>]

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)
>> <bastien.curutchet@bootlin.com> 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