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
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...
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.
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
linux-kselftest-mirror@lists.linaro.org
-
Alexis Lothoré -
Magnus Karlsson -
Stanislav Fomichev