From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8EE97457A5; Mon, 12 Aug 2024 22:54:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D062402D3; Mon, 12 Aug 2024 22:54:49 +0200 (CEST) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mails.dpdk.org (Postfix) with ESMTP id 8B29D402BB for ; Mon, 12 Aug 2024 22:54:47 +0200 (CEST) Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-2cd5e3c27c5so3125852a91.3 for ; Mon, 12 Aug 2024 13:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1723496087; x=1724100887; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QPsPOpFDsIPi8LuL+9eDLk3XMU1FJoc1bB+QNgXEVw4=; b=MNVw2r+Vk5IyUC5M1fjLPC72Dknem7/FpARLk1VDDzPwSSAXWhG+16W0zPnTPEudV1 1kZgphkC8mNh1/ViznReEkguEQTW6hB1ypJHNd5eWPv2zIkLPMf7WdDqWu6EP/WyPiMj wbRbAl7IKENO2JxwHIEyti3MxWdd5AjBAOR6g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723496087; x=1724100887; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QPsPOpFDsIPi8LuL+9eDLk3XMU1FJoc1bB+QNgXEVw4=; b=Xe6ptCmED/UFqjmVY3gSFDQdwbxD687LsszORaT07a9mfForWxnzwCHuRgOup7zE2S fGs5fNwmgt3GiX/RmqBWR7/dt2ZHgYFKWBSYWpRdofC1M0FAVn9Dc2gi7pDQDd4hTO9D Ibyqh744l3KJ67CmgZjrUdQPSQPDOqUFL+O9ORA+vup+6K1NezGeweAYm8wazSHSsuW6 c4RoDUGhBCwH4aNbFcIRmdQ84ZY2IhEqs7w4CqDH+DcCHHErOpiKeF/tIKpCIUWdHD4Y ziix5pbIvShip50Jm+Rl5lzU9fM7bf3bMQZMwnh1xbR4UCpvLOvw+s7UVvxmSy6VFxMk Bi5g== X-Forwarded-Encrypted: i=1; AJvYcCXqGpQNoyXqydhOnhqQ/CkFQiEKfUKo2nJa5rYf2M7usZGUiLS6pT/FPIRT2M3FvyuUwpmY7ubNqWZtFsM= X-Gm-Message-State: AOJu0YxKIPyhIGkGZuJe9wd8PTCqYID4McQvIsrOPpwfrrN410qLlvkb CHSHLuBy5fBTHHe1qX1YPaOEIoA5YhoOCEpL+tCg0WiwPh/xb2sLWv5OXv5ydMOiiaq1T4/vJsj V3vKuZ8O9NfD3k/2jAeA9BtswCtld+YrJ+VVehQ== X-Google-Smtp-Source: AGHT+IFfMofp/TJvq6I6XQp03H+HTITAMhWGYRohFjz4b4xQCo+S6TIvm1RvcBUxFk0c5vZ9qkNrXT+rYQvFslIKOf4= X-Received: by 2002:a17:90b:4f8b:b0:2d1:ca16:554d with SMTP id 98e67ed59e1d1-2d3924e16c4mr1733649a91.4.1723496086529; Mon, 12 Aug 2024 13:54:46 -0700 (PDT) MIME-Version: 1.0 References: <20240812134124.27637-1-dmarx@iol.unh.edu> In-Reply-To: <20240812134124.27637-1-dmarx@iol.unh.edu> From: Jeremy Spewock Date: Mon, 12 Aug 2024 16:54:35 -0400 Message-ID: Subject: Re: [RFC v1 0/2] dts: initial checksum offload suite To: Dean Marx Cc: probb@iol.unh.edu, npratte@iol.unh.edu, luca.vizzarro@arm.com, yoan.picchi@foss.arm.com, Honnappa.Nagarahalli@arm.com, paul.szczepanek@arm.com, juraj.linkes@pantheon.tech, dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hey Dean, Thanks for the patch, I left some thoughts on the point you raise below and some of the larger things I noticed throughout the series. The logic seems to all be right though and I can understand what you were going for, so the broader ideas seem good to me. On Mon, Aug 12, 2024 at 9:41=E2=80=AFAM Dean Marx wrote= : > > Test suite for verifying checksum hardware offload through the > PMD works as expected. This is done by checking the verbose output in > testpmd while in csum forwarding mode, specifically the ol_flags > section, to ensure they match the flags in the test plan. However, > there are a few issues I noticed while writing the suite that made > me hesitant to submit a patch: > > 1. SCTP hardware offload is not supported on any of the NICs I tested > on. I've tried this on mlx5, i40e, and bnxt drivers and none of them > support it. SCTP offload is used as part of almost every test case, so I > removed SCTP packets from the suite entirely. I intend to keep it that > way unless anyone is able to use the command "csum set sctp hw 0" > without an "SCTP not supported" error. > 2. There are two Tx checksum test cases, which involve checking the Tx > flags section of verbose output to ensure they match the ones in the > test plan. However, the Tx flags don't appear to change at all > depending on what packet you send to testpmd, which leaves me with no > way to verify correct behavior. I'm considering removing the Tx cases > entirely, but they are a large chunk of the suite so if anyone disagrees > I can look for more of a workaround. > As for the Tx issue, I have also noticed that these flags are inconsistent. It looks like the Tx side of things have flags representing if there is checksum data for the various layers, but even then it doesn't show up in the verbose output when there is verbose information. I think that if it isn't consistent then we can't write a test suite that is generic enough to be run on the hardware and it probably makes more sense to just leave it out of the suite. I'm honestly not sure if it is a bug or just a misunderstanding with what these flags should be doing since the Tx flags are much less clear to me than the Rx. Regardless, it's not like it's something we can search for with a capability or anything so we don't have a great mechanism for getting this to work if it truly is just something where different drivers do it differently. > If anyone has any comments or advice about the issues above it is > greatly appreciated. > > Dean Marx (2): > dts: add csum HW offload to testpmd shell > dts: checksum offload test suite > > dts/framework/config/conf_yaml_schema.json | 3 +- > dts/framework/remote_session/testpmd_shell.py | 94 ++++++ > dts/tests/TestSuite_checksum_offload.py | 288 ++++++++++++++++++ > 3 files changed, 384 insertions(+), 1 deletion(-) > create mode 100644 dts/tests/TestSuite_checksum_offload.py > > -- > 2.44.0 >