Hello, 24/06/2020 17:14, Owen Hilyard: > Hello, > > To my understanding, this feature is the ability of the driver to > offload checksum verification on received packets to the hardware > level. If that is incorrect, then please let me know.
Yes, you're right. You can find some pointers in the doc: http://doc.dpdk.org/guides/nics/features.html#l3-checksum-offload > My plan for testing this feature is as follows; > > This feature will be verified by a series of test cases sharing a > single helper method. It will be located inside of the > “checksum_offload” test suite. The test case names will follow the > pattern of test_hardware_checksum_check_<L3 Protocol>_<L4 Protocol>. > Each test case will send packets with a L3/L4 combination, the > complete list being IP/UDP, IP/TCP, IP/SCTP, IPv6/UDP and IPv6/TCP. Some HW may do the checksum of tunnelled packets as well. In this case, the default is the inner layer, while the outer layer requires some specific flags (DEV_RX_OFFLOAD_OUTER_*). > Each packet will contain a payload of 50 bytes of 0x58. Each test case > will consist of first enabling verbosity level 1 on the dut’s testpmd > instance. This will cause testpmd to display good/bad checksum flags. > After that, packet forwarding will be started. Then, a packet with a > checksum will be sent to the dut and the output from testpmd will be > checked to ensure that the flags are correct. Next, a packet will be > sent which intentionally has a bad checksum (0xF). In the case of > packets using IPv4, both the L3 and L4 checksums will be set to 0xF. > The flags will then be checked for the correct flags, in this case bad > checksum flags. > > I decided to separate out the test cases instead of doing it like the > other ones in that area of the test suite because I noticed that a NIC > doesn't necessarily need to support offloading all checksum types, and > if I wrote the tests in the same way as the other ones in the test, it > would fail everything if the first protocol wasn't supported, No, if it is not supported, the result must have a special value "UNKNOWN". > rather > than failing only that protocol. I thought that the solution of having > more test cases, although it would lead to slower test times and more > verbose output, would be beneficial as it would allow for more > granular pass/fail results. The helper method for the tests would go > something like this: > > 1. Start TestPmd > 2. Enable hardware checksum > 3. Fill in template parameters in the strings provided by the test > method with mac addresses and packet options. > 4. Send a packet with a bad checksum, and then check for the flags > which mean invalid checksum. > 5. Send a packet with a good checksum, and then check for the flags > which mean valid checksum. > > Please let me know if you think any part of this methodology is flawed > or if there are certain things I should be aware of such as a special > way to enable these checks aside from the checksum aside from > TestChecksumOffload::checksum_enablehw. I think you should describe all the protocols you want to test. Thanks > Thanks, > Owen Hilyard > Software Developer > UNH Interoperability Lab
