DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Hardware Checksum Checks Offload Feature
@ 2020-06-24 15:14 Owen Hilyard
  2020-06-24 20:20 ` Thomas Monjalon
  0 siblings, 1 reply; 7+ messages in thread
From: Owen Hilyard @ 2020-06-24 15:14 UTC (permalink / raw)
  To: dev, dts
  Cc: Thomas Monjalon, ferruh.yigit, arybchenko, olivier.matz,
	david.marchand, ivan.malov, bruce.richardson, jerin.jacob,
	Lincoln Lavoie, 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. 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-06-29 14:41 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-24 15:14 [dpdk-dev] Hardware Checksum Checks Offload Feature Owen Hilyard
2020-06-24 20:20 ` Thomas Monjalon
2020-06-25 14:51   ` Owen Hilyard
2020-06-25 15:25     ` Thomas Monjalon
2020-06-25 15:54       ` Owen Hilyard
2020-06-29 14:01         ` Owen Hilyard
2020-06-29 14:41           ` Thomas Monjalon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).