Re: [dts] Hardware Checksum Checks Offload Feature

[Thomas Monjalon <thomas@monjalon.net>]

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