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 5F494A0350; Wed, 24 Jun 2020 22:20:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 526E71DA0F; Wed, 24 Jun 2020 22:20:28 +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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedvkeetveeihfegfedtfeejueekkeekueevgfejuedviedvvdev uefgteevtdefveenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefge drvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: 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 To: Owen Hilyard 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 , Owen Hilyard , rasland@mellanox.com, j.hendergart@f5.com Date: Wed, 24 Jun 2020 22:20:18 +0200 Message-ID: <2532193.hmao2X3YlT@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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" 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__. > 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