Question about test_xsk.sh

Question about test_xsk.sh

[Alexis Lothoré]

Hello all,

I was looking  at other test candidates for conversion to bpf test_progs
framework (to increase automatic testing scope) and found test_xsk.sh, which
does not seem to have coverage yet in test_progs. This test validates the AF_XDP
socket behavior with different XDP modes (SKB, DRV, zero copy) and socket
configuration (normal, busy polling).

The testing program looks pretty big, considering all files involved
(test_xsk.sh, xskxceiver.c, xsk.c, the different XDP programs) and the matrix of
tests it runs. So before really diving into it, I would like to ask:
- is it indeed a good/relevant target for integration in test_progs (all tests
look like functional tests, so I guess it is) ?
- if so, is there anyone already working on this ?
- multiple commits on xskxceiver.c hint that the program is also used for
testing on real hardware, could someone confirm that it is still the case
(similar need has been seen with test_xdp_features.sh for example) ? If so, it
means that the current form must be preserved, and it would be an additional
integration into test_progs rather a conversion (then most of the code should be
shared between the non-test_progs and the test_progs version)

Thanks,

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Question about test_xsk.sh

[Stanislav Fomichev]

On 12/20, Alexis Lothoré wrote:
> Hello all,
> 
> I was looking  at other test candidates for conversion to bpf test_progs
> framework (to increase automatic testing scope) and found test_xsk.sh, which
> does not seem to have coverage yet in test_progs. This test validates the AF_XDP
> socket behavior with different XDP modes (SKB, DRV, zero copy) and socket
> configuration (normal, busy polling).
> 
> The testing program looks pretty big, considering all files involved
> (test_xsk.sh, xskxceiver.c, xsk.c, the different XDP programs) and the matrix of
> tests it runs. So before really diving into it, I would like to ask:
> - is it indeed a good/relevant target for integration in test_progs (all tests
> look like functional tests, so I guess it is) ?
> - if so, is there anyone already working on this ?
> - multiple commits on xskxceiver.c hint that the program is also used for
> testing on real hardware, could someone confirm that it is still the case
> (similar need has been seen with test_xdp_features.sh for example) ? If so, it
> means that the current form must be preserved, and it would be an additional
> integration into test_progs rather a conversion (then most of the code should be
> shared between the non-test_progs and the test_progs version)

Since no one came back to you, here is my attempt to answer.. It is a
good target but it is indeed a good idea to preserve the ability to
run it outside of test_progs framework. Maybe we can eventually run
it with the real hw (in loopback mode) from
tools/testing/selftests/rivers/net/hw. And I don't think anybody
is working on integrating it into test_progs. But Magnus/Maciej should
have more context...

Re: Question about test_xsk.sh

[Magnus Karlsson]

On Thu, 2 Jan 2025 at 23:31, Stanislav Fomichev <stfomichev@gmail.com> wrote:
>
> On 12/20, Alexis Lothoré wrote:
> > Hello all,
> >
> > I was looking  at other test candidates for conversion to bpf test_progs
> > framework (to increase automatic testing scope) and found test_xsk.sh, which
> > does not seem to have coverage yet in test_progs. This test validates the AF_XDP
> > socket behavior with different XDP modes (SKB, DRV, zero copy) and socket
> > configuration (normal, busy polling).
> >
> > The testing program looks pretty big, considering all files involved
> > (test_xsk.sh, xskxceiver.c, xsk.c, the different XDP programs) and the matrix of
> > tests it runs. So before really diving into it, I would like to ask:
> > - is it indeed a good/relevant target for integration in test_progs (all tests
> > look like functional tests, so I guess it is) ?
> > - if so, is there anyone already working on this ?
> > - multiple commits on xskxceiver.c hint that the program is also used for
> > testing on real hardware, could someone confirm that it is still the case
> > (similar need has been seen with test_xdp_features.sh for example) ? If so, it
> > means that the current form must be preserved, and it would be an additional
> > integration into test_progs rather a conversion (then most of the code should be
> > shared between the non-test_progs and the test_progs version)
>
> Since no one came back to you, here is my attempt to answer.. It is a
> good target but it is indeed a good idea to preserve the ability to
> run it outside of test_progs framework. Maybe we can eventually run
> it with the real hw (in loopback mode) from
> tools/testing/selftests/rivers/net/hw. And I don't think anybody
> is working on integrating it into test_progs. But Magnus/Maciej should
> have more context...

Sorry Alexis for the late reply. I have enjoyed a long vacation over
the holidays.

I agree with Stanislav's reply. The only thing I can add is that we
really want to preserve the ability to run on real HW as the majority
of bugs we find are indeed in the zero-copy driver implementations. So
these real HW/driver tests are more useful to us than the self
contained tests using veth.

Re: Question about test_xsk.sh

[Alexis Lothoré]

Hello Stanislas, Magnus,

On 1/3/25 10:36, Magnus Karlsson wrote:
> On Thu, 2 Jan 2025 at 23:31, Stanislav Fomichev <stfomichev@gmail.com> wrote:
>>
>> On 12/20, Alexis Lothoré wrote:
>>> Hello all,
>>>
>>> I was looking  at other test candidates for conversion to bpf test_progs
>>> framework (to increase automatic testing scope) and found test_xsk.sh, which
>>> does not seem to have coverage yet in test_progs. This test validates the AF_XDP
>>> socket behavior with different XDP modes (SKB, DRV, zero copy) and socket
>>> configuration (normal, busy polling).
>>>
>>> The testing program looks pretty big, considering all files involved
>>> (test_xsk.sh, xskxceiver.c, xsk.c, the different XDP programs) and the matrix of
>>> tests it runs. So before really diving into it, I would like to ask:
>>> - is it indeed a good/relevant target for integration in test_progs (all tests
>>> look like functional tests, so I guess it is) ?
>>> - if so, is there anyone already working on this ?
>>> - multiple commits on xskxceiver.c hint that the program is also used for
>>> testing on real hardware, could someone confirm that it is still the case
>>> (similar need has been seen with test_xdp_features.sh for example) ? If so, it
>>> means that the current form must be preserved, and it would be an additional
>>> integration into test_progs rather a conversion (then most of the code should be
>>> shared between the non-test_progs and the test_progs version)
>>
>> Since no one came back to you, here is my attempt to answer.. It is a
>> good target but it is indeed a good idea to preserve the ability to
>> run it outside of test_progs framework. Maybe we can eventually run
>> it with the real hw (in loopback mode) from
>> tools/testing/selftests/rivers/net/hw. And I don't think anybody
>> is working on integrating it into test_progs. But Magnus/Maciej should
>> have more context...
> 
> Sorry Alexis for the late reply. I have enjoyed a long vacation over
> the holidays.

No worry, I did not expect quick answers with christmas holidays coming, thanks
to both of you for your answers.

> I agree with Stanislav's reply. The only thing I can add is that we
> really want to preserve the ability to run on real HW as the majority
> of bugs we find are indeed in the zero-copy driver implementations. So
> these real HW/driver tests are more useful to us than the self
> contained tests using veth.

ACK. Based on your answers, and since test_xsk.sh seems to also cover many core
features regarding AF_XDP sockets, I'll work on integrating this in test_progs.
I'll see if the code can be shared between a "on hw" test and a "test progs"
test, and if not possible (eg undesirable code dependency between different kind
of selftests ?), at least replicate the basic AF_XDP tests in test_progs.

Thanks,

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com