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. 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. 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, 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. Thanks, Owen Hilyard Software Developer UNH Interoperability Lab
