Marcus Wichelmann wrote: > The existing XDP metadata test works by creating a veth pair and > attaching XDP & TC programs that drop the packet when the condition of > the test isn't fulfilled. The test then pings through the veth pair and > succeeds when the ping comes through. > > While this test works great for a veth pair, it is hard to replicate for > tap devices to test the XDP metadata support of them. A similar test for > the tun driver would either involve logic to reply to the ping request, > or would have to capture the packet to check if it was dropped or not. > > To make the testing of other drivers easier while still maximizing code > reuse, this commit refactors the existing xdp_context_functional test to > use a test_result map. Instead of conditionally passing or dropping the > packet, the TC program is changed to copy the received metadata into the > value of that single-entry array map. Tests can then verify that the map > value matches the expectation. > > This testing logic is easy to adapt to other network drivers as the only > remaining requirement is that there is some way to send a custom > Ethernet packet through it that triggers the XDP & TC programs. > > The Ethernet header of that custom packet is all-zero, because it is not > required to be valid for the test to work. The zero ethertype also helps > to filter out packets that are not related to the test and would > otherwise interfere with it. > > The payload of the Ethernet packet is used as the test data that is > expected to be passed as metadata from the XDP to the TC program and > written to the map. It has a fixed size of 32 bytes which is a > reasonable size that should be supported by both drivers. Additional > packet headers are not necessary for the test and were therefore skipped > to keep the testing code short. > > This new testing methodology no longer requires the veth interfaces to > have IP addresses assigned, therefore these were removed. > > Signed-off-by: Marcus Wichelmann <marcus.wichelmann@xxxxxxxxxxxxxxxx> Reviewed-by: Willem de Bruijn <willemb@xxxxxxxxxx>
