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 76C68A0519; Wed, 24 Jun 2020 17:15:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 034B21DA0F; Wed, 24 Jun 2020 17:15:30 +0200 (CEST) Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by dpdk.org (Postfix) with ESMTP id A55161D9E6 for ; Wed, 24 Jun 2020 17:15:27 +0200 (CEST) Received: by mail-qk1-f195.google.com with SMTP id q198so2151338qka.2 for ; Wed, 24 Jun 2020 08:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=wspGWzvUrNNwDYn6XUNJIugXPrbgwXmuVI5bhQ+uWns=; b=iSw6PpMEDFbHlUsAQ5JR7TKOmTWB2YhbZonNqAJqP2BM9O6dsU0CGfyvFPvEyvNjJo MB71epmUxepSfRd1oTM6/l6rOgKFAXhrEdflK2bAtMDxKVdTgs8gO0qPqlC3Soh8+PHv C9yRnucq5IOct7qHUmo4Tc2zxzX0Qdu9KIW/o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=wspGWzvUrNNwDYn6XUNJIugXPrbgwXmuVI5bhQ+uWns=; b=Y+yjx92jS12l1xfYaOti/gPvOiLWX6k6ZCrwB+9R9k8LvG2vbzk+jAOp4rVu2q+is/ gQH3Z6SvGmrNxSqMaEpHtq3qDdffTgxsTnFdx23t95RvZLEuBziORcPbYX7DRhT2cKZL dJjRrGSW61VkJU0Smdiz/CH+febC1Dfm+eOGg7C8ojcU7WBEAPgOsEbnPuDpVqJYukgf 9mgwTD81mHLoojGj0+43Y6NUClvr+s8nKS4moF7HY90K+oyH8XecUysBYDc9E+rhg2WY IkZzv4o81VWgTIM4xWuudLZLz+WKh61n4oqu5/ZZpjumsPAkjFAJGKdGIaE1ua0R7yNk 0MzA== X-Gm-Message-State: AOAM533rWSgcwFInj102iZqw+PKH5hpbmmCJRnCp2wbTbld0mxSBjHoU 9BTBeWhDTiMxIAr6l0iYedTxxc/uPwQjtxcrHKGriA== X-Google-Smtp-Source: ABdhPJwUm2QKJaN2o0JWS1N17OUdkwbcooiOlQubRo7Y1BAjI0odgOR4nC4yaf7IPFvh9t5vMSs3cJw7OYvXrLTOta0= X-Received: by 2002:a37:5b81:: with SMTP id p123mr17383145qkb.150.1593011725919; Wed, 24 Jun 2020 08:15:25 -0700 (PDT) MIME-Version: 1.0 From: Owen Hilyard Date: Wed, 24 Jun 2020 11:14:50 -0400 Message-ID: To: dev@dpdk.org, dts@dpdk.org Cc: Thomas Monjalon , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [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, 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 =E2=80=9Cchecksum_offload=E2=80=9D test suite. The test case names will fol= low 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. 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 testp= md 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