test suite reviews and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Owen Hilyard <ohilyard@iol.unh.edu>
Cc: dev@dpdk.org, dts@dpdk.org, 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>,
	rasland@mellanox.com, j.hendergart@f5.com
Subject: Re: [dts] Hardware Checksum Checks Offload Feature
Date: Wed, 24 Jun 2020 22:20:18 +0200	[thread overview]
Message-ID: <2532193.hmao2X3YlT@thomas> (raw)
In-Reply-To: <CAHx6DYBtSsZmAViVAmtPrA20J3J03YUYRs1D1RXxmqPUnP2rUA@mail.gmail.com>

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



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

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 15:14 Owen Hilyard
2020-06-24 20:20 ` Thomas Monjalon [this message]
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=2532193.hmao2X3YlT@thomas \
    --to=thomas@monjalon.net \
    --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=j.hendergart@f5.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=lylavoie@iol.unh.edu \
    --cc=ohilyard@iol.unh.edu \
    --cc=olivier.matz@6wind.com \
    --cc=rasland@mellanox.com \
    /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).