Magnus Karlsson wrote: > On Tue, 11 Jun 2024 at 22:43, YiFei Zhu <zhuyifei@xxxxxxxxxx> wrote: > > > > We have observed that hardware NIC drivers may have faulty AF_XDP > > implementations, and there seem to be a lack of a test of various modes > > in which AF_XDP could run. This series adds a test to verify that NIC > > drivers implements many AF_XDP features by performing a send / receive > > of a single UDP packet. > > > > I put the C code of the test under selftests/bpf because I'm not really > > sure how I'd build the BPF-related code without the selftests/bpf > > build infrastructure. > > Happy to see that you are contributing a number of new tests. Would it > be possible for you to integrate this into the xskxceiver framework? Makes sense, we'll need to take a look. This is an internal test that we have been using for a long time in our test framework. My mistake for not keeping up at all with the changes to xskxceiver.c in the meantime. We want to test each case independently. Including a few non obvious cases that we discovered from real use, notably - Using XSK only for Tx, without installing an Rx program - Using XSK with an empty fill queue, filling it after bind > You can find that in selftests/bpf too. By default, it will run its > tests using veth, but if you provide an interface name after the -i > option, it will run the tests over a real interface. I put the NIC in > loopback mode to use this feature, but feel free to add a new mode if > necessary. We do really want two machine tests, not loopback mode. Also to integrate into the drv-net infrastructure. Another non-obvious feature is to test one side AF_XDP and use PF_PACKET on the other side, to be able to isolate and exercise only the Tx or Rx path in a test. > A lot of the setup and data plane code that you add already > exists in xskxceiver, so I would prefer if you could reuse it. Your > tests are new though and they would be valuable to have. > > You could make the default packet that is sent in xskxceiver be the > UDP packet that you want and then add all the other logic that you > have to a number of new tests that you introduce.
