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