[dpdk-dev] Hardware Checksum Checks Offload Feature

[dpdk-dev] Hardware Checksum Checks Offload Feature

[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

Re: [dpdk-dev] Hardware Checksum Checks Offload Feature

[Thomas Monjalon]

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

Re: [dpdk-dev] Hardware Checksum Checks Offload Feature

[Owen Hilyard]

Hello,

In regards to the outer layers, having grepped through the code for
"[\w_]+_GOOD|[\w_]+_BAD", I wasn't able to find the flags that I expected.
I expected something like PKT_RX_OUTER_IP_CKSUM_BAD and
PKT_RX_OUTER_IP_CKSUM_GOOD to show up since that seems to be the format for
flags to be printed, but there wasn't anything in the grep output related
to that. Am I missing something? I can do outer UDP fairly easily, but it
doesn't look like there is support for outer TCP and outer SCTP in TestPmd.
I will plan to add tests

> > 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".

To clarify my meaning there, I mean that the verify statements in the test
case will abort the test on the first failed statement, so I am splitting
the tests up so that I don't need to collect all of the errors and then
spit them all out at once. Also, as far as I can tell, unknown only occurs
when it is not possible to decode a layer. The NIC I am testing with
doesn't support offloading outer udp, and TestPmd gives me an error message
and then leaves the option set to software mode. When I send a packet
without any tunneling, then it gives me something like
"PKT_RX_OUTER_L4_CKSUM_UNKNOWN". Is this assessment incorrect?

>  I think you should describe all the protocols you want to test.

Could you please elaborate on this?

Thanks for your feedback

Re: [dpdk-dev] Hardware Checksum Checks Offload Feature

[Thomas Monjalon]

> >  I think you should describe all the protocols you want to test.
> 
> Could you please elaborate on this?

I mean doing a test matrix inluding IP, TCP, UDP, VXLAN, GENEVE, etc.

Re: [dpdk-dev] Hardware Checksum Checks Offload Feature

[Owen Hilyard]

I can do that.

Thanks for the clarification

On Thu, Jun 25, 2020 at 11:25 AM Thomas Monjalon <thomas@monjalon.net>
wrote:

> > >  I think you should describe all the protocols you want to test.
> >
> > Could you please elaborate on this?
>
> I mean doing a test matrix inluding IP, TCP, UDP, VXLAN, GENEVE, etc.
>
>
>

Re: [dpdk-dev] Hardware Checksum Checks Offload Feature

[Owen Hilyard]

It seems that GENEVE is not supported in the version of scapy that is
currently used. It is supported in the next version. I didn't want to make
the decision to either force an update, spend time attempting to backport
the protocol and then adding a way to automatically add that patch onto an
existing version, or drop the protocol from the test matrix without
community input.

Thoughts?

On Thu, Jun 25, 2020 at 11:54 AM Owen Hilyard <ohilyard@iol.unh.edu> wrote:

> I can do that.
>
> Thanks for the clarification
>
> On Thu, Jun 25, 2020 at 11:25 AM Thomas Monjalon <thomas@monjalon.net>
> wrote:
>
>> > >  I think you should describe all the protocols you want to test.
>> >
>> > Could you please elaborate on this?
>>
>> I mean doing a test matrix inluding IP, TCP, UDP, VXLAN, GENEVE, etc.
>>
>>
>>

Re: [dpdk-dev] Hardware Checksum Checks Offload Feature

[Thomas Monjalon]

29/06/2020 16:01, Owen Hilyard:
> It seems that GENEVE is not supported in the version of scapy that is
> currently used. It is supported in the next version. I didn't want to make
> the decision to either force an update, spend time attempting to backport
> the protocol and then adding a way to automatically add that patch onto an
> existing version, or drop the protocol from the test matrix without
> community input.
> 
> Thoughts?

I think you can skip GENEVE for now.


> On Thu, Jun 25, 2020 at 11:54 AM Owen Hilyard <ohilyard@iol.unh.edu> wrote:
> 
> > I can do that.
> >
> > Thanks for the clarification
> >
> > On Thu, Jun 25, 2020 at 11:25 AM Thomas Monjalon <thomas@monjalon.net>
> > wrote:
> >
> >> > >  I think you should describe all the protocols you want to test.
> >> >
> >> > Could you please elaborate on this?
> >>
> >> I mean doing a test matrix inluding IP, TCP, UDP, VXLAN, GENEVE, etc.
> >>
> >>
> >>
>