On Thu, 2 Jan 2025 at 23:31, Stanislav Fomichev <stfomichev@xxxxxxxxx> 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.
