From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 7C9FFA0350;
	Wed, 24 Jun 2020 22:20:27 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id EC23B1D9F8;
	Wed, 24 Jun 2020 22:20:26 +0200 (CEST)
Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com
 [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 71D8D1D9F7;
 Wed, 24 Jun 2020 22:20:25 +0200 (CEST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47])
 by mailnew.nyi.internal (Postfix) with ESMTP id 0C6D85805C5;
 Wed, 24 Jun 2020 16:20:25 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Wed, 24 Jun 2020 16:20:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm1; bh=
 DottLP8yEviExP8dg1ZZ4fSpjYN5z4PTyn0S5q7hzBM=; b=m+Ts64GRCHkhIv8q
 v76av68bn1vV5324+7dopkGJCwzcNpULbM3Mi+wykT0npg+kgW9BncSOivljhV8+
 a2C6v4AYDd/oasWOtIr/gBY2IS5VBA+bOJkzEdaNKFf+9aW+cDjcKX1rMH380Ulu
 YuW8m2Z2A+VuvnixxEK2RjA/36DYBeGRFOCQeElMyQfmmwt9Q3T6g/sS9dxbot1K
 KnrgQMKpVEkPwAW9GAcg7UYRmTmPr/BQWVQAFVUrTlqF0mmBNOLGHaUFbI+WN0lf
 6oBfqVMVe+93N2Mja/FTO8KVPIqgI3vgt9+hZYOp/GLAtOkr7kYYrvK30s40uyOI
 beI9Gw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm3; bh=DottLP8yEviExP8dg1ZZ4fSpjYN5z4PTyn0S5q7hz
 BM=; b=T43kZrPJQDNVZ/4jq9BXSjDWeYG3E5qUVvTmEdjDRSpPnTFy5jNMWGCXD
 RfiwxDlLR/sjma3YOPLJ3flSuMLYKVXFRggO9PyrAuixhWpY7Eq+D2ZCaqJDOdrz
 jeefm8keepb1g2UzhnVUdkoiiV9Q+sQQdpihC8i9g1Z8Ea+d83/OWCx8hotM/I9g
 LXIc/0swIGqyU8G+xC7/fpsLuxE1R/i154Dd/6tU4vX7xF+nGaEN3K7EmQHFJhfn
 WPWRd4j4hxhaqqYRIols2L/cKjh6JSm831m6Fc4n9oGOJL5zqBkZDCFgGCkt3r/P
 +p2pqRCvaLGQ0ntQ64ZuxKPbeJimA==
X-ME-Sender: <xms:hbXzXm92HE_UaJsVxOzulw9Yxa2NHYFU_DL44vZ7_AAkhCqIWFOx0g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgudegfecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpedvkeetveeihfegfedtfeejueekkeekueevgfejuedviedvvdev
 uefgteevtdefveenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefge
 drvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl
 fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:hbXzXmtD0PlgTjA2g-cumiuL-LzbaxZQsXF5v08fxpSMBw0ruVT6zg>
 <xmx:hbXzXsAuQ2IN71nNkcCtyGSL8pXBUYcPpbHubAKIRiMwv-IwCVWEVg>
 <xmx:hbXzXufTfhDsZNQWAtG5Gb-L2etAPnJz3zdl5iJmpwy15ribakHZwQ>
 <xmx:ibXzXmq8nO_ZiTBVtGI6k2bqyAtxTHYtIOrBC5jFBlOwCrWOPY3Q4w>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id F4225328005D;
 Wed, 24 Jun 2020 16:20:19 -0400 (EDT)
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
Date: Wed, 24 Jun 2020 22:20:18 +0200
Message-ID: <2532193.hmao2X3YlT@thomas>
In-Reply-To: <CAHx6DYBtSsZmAViVAmtPrA20J3J03YUYRs1D1RXxmqPUnP2rUA@mail.gmail.com>
References: <CAHx6DYBtSsZmAViVAmtPrA20J3J03YUYRs1D1RXxmqPUnP2rUA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] Hardware Checksum Checks Offload Feature
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hello,

24/06/2020 17:14, Owen Hilyard:
> Hello,
>=20
> 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;
>=20
> This feature will be verified by a series of test cases sharing a
> single helper method. It will be located inside of the
> =E2=80=9Cchecksum_offload=E2=80=9D test suite. The test case names will f=
ollow 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=E2=80=99s tes=
tpmd
> 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.
>=20
> 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:
>=20
> 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.
>=20
> 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