From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0C7AFA0350; Thu, 25 Jun 2020 16:52:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EB0C62A66; Thu, 25 Jun 2020 16:52:35 +0200 (CEST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by dpdk.org (Postfix) with ESMTP id 4C2E32A66 for ; Thu, 25 Jun 2020 16:52:34 +0200 (CEST) Received: by mail-qk1-f171.google.com with SMTP id f18so5554426qkh.1 for ; Thu, 25 Jun 2020 07:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vynny0Xdjm7e1ZPVWE3J1wIcjSCrf3XW5OueOoD3s7k=; b=XLi+pLFkRom5yEQ7fRJQSd3KV8VAwFCIeUGktDa4TCjMHGABZlPjLt5QipeQRI6TeQ MonTmTMhDjYgsau8Acc2+EEl8IfXpnqRn8pHbUUXttM/cPPnnssIcZ083u1lh5gBSgHd k/YG30h0dng1aVyVVFDFBLMXeGOtd8wZSJZWQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vynny0Xdjm7e1ZPVWE3J1wIcjSCrf3XW5OueOoD3s7k=; b=UbTEZh04O2A+jqxYTatgGYmrUx5DoYoEHKuXsHCz1mURNn5IJCq0+AztOO9B9A/nLB KU73KUmntGq2gWzUR0bIZxrgnKFtDWMuOeIJqCnqhVnHGBBhm9Ae3g5wKeXCSv/Co5lJ iP9enUMUNVW1ENyifrLbEG1RI7fXYsAxCB/RT8W24gPw1ortDlEs8Sj0jT5wmGAU7plG 8/j49oKuECuOzKTk+uj2M171YU7+7OsMRgD8o7uzpaZYe9MGfH+1rowxbILx15+CVz4h OKrGpt0noCpv/GnATP0wFoWZxkgXg09qH6KkgMQCEVMVGaVxupdviGeP7FzyULrSUre6 SB0A== X-Gm-Message-State: AOAM531iRcN4luKKwReLfhKhICdHisVrglLg9nhiblufNN7kT9UTDLVd TDJW27EyzNJoPfxIvv6zVQhTxaJzn3lz4lRpRFtAUg== X-Google-Smtp-Source: ABdhPJwU43KjI2RPSx7Z1vlOJLxBrfu3xwqokrGNQuwNxmKSOeasBdD+wBUKkEdZ2ziQHY4wfOqLrcTJOonHmyln4B0= X-Received: by 2002:a37:a204:: with SMTP id l4mr12261260qke.200.1593096753639; Thu, 25 Jun 2020 07:52:33 -0700 (PDT) MIME-Version: 1.0 References: <2532193.hmao2X3YlT@thomas> In-Reply-To: <2532193.hmao2X3YlT@thomas> From: Owen Hilyard Date: Thu, 25 Jun 2020 10:51:58 -0400 Message-ID: To: Thomas Monjalon Cc: dev@dpdk.org, dts@dpdk.org, ferruh.yigit@intel.com, arybchenko@solarflare.com, Olivier Matz , david.marchand@redhat.com, ivan.malov@oktetlabs.ru, bruce.richardson@intel.com, jerin.jacob@caviumnetworks.com, Lincoln Lavoie , rasland@mellanox.com, j.hendergart@f5.com Content-Type: multipart/alternative; boundary="000000000000181b8005a8e9be72" Subject: Re: [dts] Hardware Checksum Checks Offload Feature X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org Sender: "dts" --000000000000181b8005a8e9be72 Content-Type: text/plain; charset="UTF-8" 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 --000000000000181b8005a8e9be72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

In regards to the outer lay= ers, 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 u= p 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 su= pport for outer TCP and outer SCTP in TestPmd. I will plan to add tests=C2= =A0

> > I decided to separate out the test cases instead of do= ing it like the
> > other ones in that area of the test suite beca= use I noticed that a NIC
> > doesn't necessarily need to suppo= rt offloading all checksum types, and
> > if I wrote the tests in = the same way as the other ones in the test, it
> > would fail ever= ything if the first protocol wasn't supported,
>
> No, if i= t 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 s= plitting 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 on= ly occurs when it is not possible to decode a layer. The NIC I am testing w= ith 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 pac= ket without any tunneling, then it gives me something like "PKT_RX_OUT= ER_L4_CKSUM_UNKNOWN". Is this assessment=C2=A0incorrect?

> = =C2=A0I think you should describe all the protocols you want to test.
Could you please elaborate on this?=C2=A0

Thanks for your feedback
--000000000000181b8005a8e9be72--