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 CE771A0350; Wed, 24 Jun 2020 17:15:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 942221D9EE; Wed, 24 Jun 2020 17:15:28 +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 C54321D9E6 for ; Wed, 24 Jun 2020 17:15:26 +0200 (CEST) Received: by mail-qk1-f195.google.com with SMTP id 80so2131258qko.7 for ; Wed, 24 Jun 2020 08:15:26 -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=iYn1/0IZ/JXUyWZpmj7FgmuM6RlGAnVvShNeLZVnfkSyHtOv3WpRsWLMG6sUp5yDx8 Sa9s2LxQ3uqF9RtEJj8IcBOpoq7Fc1sgWzm8nRDmPE5fMZb7W9+3hMcacgf8qFmY9CvG EgdVProzxTcprTQQtGOBC5YvNizjQu6vyfeWD+O5wsuVUuVYMhly1SYU8IUC0+rc6Azm 1VTp7KfcwPiDPkvYLOd67Q6WosHnQHJORs+6AuCPkEapBEtj77LRgV3Gg8g2VaIfKEqE LSfLXd5/BN+2OteP+w6wvoVf5eFi8SvDy2l6aV7oejRcPYzSyElkOAO1XSqRFvb6XqsT sQLA== X-Gm-Message-State: AOAM530FZNAimnCFQ/iErVEmL7rqH/ibweJdAtMjSC6h5tMVndqFLjdr 6GR94XCQfHGX9MHYwlVFmLmGyzyc7B+c3lAgtq+L3RdCCSobX7xq 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: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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