DPDK patches and discussions
 help / color / mirror / Atom feed
From: Owen Hilyard <ohilyard@iol.unh.edu>
To: dev@dpdk.org, dts@dpdk.org
Cc: Thomas Monjalon <thomas@monjalon.net>,
	ferruh.yigit@intel.com, arybchenko@solarflare.com,
	 olivier.matz@6wind.com, david.marchand@redhat.com,
	ivan.malov@oktetlabs.ru,  bruce.richardson@intel.com,
	jerin.jacob@caviumnetworks.com,
	 Lincoln Lavoie <lylavoie@iol.unh.edu>,
	Owen Hilyard <ohilyard@iol.unh.edu>
Subject: [dpdk-dev] Hardware Checksum Checks Offload Feature
Date: Wed, 24 Jun 2020 11:14:50 -0400	[thread overview]
Message-ID: <CAHx6DYBtSsZmAViVAmtPrA20J3J03YUYRs1D1RXxmqPUnP2rUA@mail.gmail.com> (raw)

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

             reply	other threads:[~2020-06-24 15:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 15:14 Owen Hilyard [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHx6DYBtSsZmAViVAmtPrA20J3J03YUYRs1D1RXxmqPUnP2rUA@mail.gmail.com \
    --to=ohilyard@iol.unh.edu \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dts@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=ivan.malov@oktetlabs.ru \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=lylavoie@iol.unh.edu \
    --cc=olivier.matz@6wind.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).