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 61D2445DAF; Wed, 27 Nov 2024 04:21:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2DB464027A; Wed, 27 Nov 2024 04:21:21 +0100 (CET) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by mails.dpdk.org (Postfix) with ESMTP id 7F78D4026C for ; Wed, 27 Nov 2024 04:21:19 +0100 (CET) Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-7ea8de14848so4843203a12.2 for ; Tue, 26 Nov 2024 19:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1732677678; x=1733282478; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=oqb2YOYknAUmkmYQx4M/WWKJzjKnBL7Xs7RvxFzSvnM=; b=qf9EJ1XLFL/KaXnKUYKFx+/54gNP1OUvNokeiJrRpOb20GWMdedL0D+rIRceI9uAu+ jb0E0gz2kZeh3wIwIc03oEyDoz1CTSdt+76bkRmJ8miBCh7Ac8q9s2YgZ2rOwq52RtTn 3blBgvkLx9UWiOVtzWcbO2IP4oNzAu3g7xCI4NGNuAGAEoD2KxyNGht5dcyMd3Ofpkuj BFyt993nHxrmJzFd0EN/ASh/9KPf60Cse//nVHPT/wgsnREoe1lIQjsPavCp/bL8cv9q 3SO/ImJhbSVWUKuL7IvOgel0xZcp7hZWVhnZ8LKAwYLjWICdBwQMWyW0kJ4UhGTvqxko uFCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732677678; x=1733282478; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oqb2YOYknAUmkmYQx4M/WWKJzjKnBL7Xs7RvxFzSvnM=; b=Az+NtvF3ar3X0E/pCEoyRz3Vvu60+9+ppbezTv8bLtGnJYWXr/U12Jw4WFfvwVfv16 lMoO501N5DAS6TKr6pLjOX8yjukOmK/avaOk4axkjNXCMUHA/bbSFi6E3gILeW5ucNdU wr0Nd4d5Zs7srA0/LdclHz0s5OJ1rR18VrimqN+k0hjuXUBUWCN3IbeppZWQ1LHG6HiW Ok85z4dMYCVNkYxdsa5U+56oyGFiUZwfJYAxjU9MdGf5DGNKPQOvMVbbmEO+O8Y4bx7G Z53bnx9Z+IOtAbX1JyZEXdJPea9jw/xcd6D1UplLN2jxInnIHPJPgwQexKdubRxgFi9/ piYw== X-Gm-Message-State: AOJu0YzhIymaJmNXu/o/LXxUa0l28Dv0S4mVbqmbOfbTimozQzYq4C/M 7yJJaOmoHRU442BVNMUGHQPP0Gvvk6W+hOD9J4HMOl7FhUiUvGT/GJ3GdDrFLq4= X-Gm-Gg: ASbGncvQz9YPsOXbVGWGw2qYGkaoM6TnV7CvBpEEcrGE9wkpci1Jw9lebBmYb+UGLcE DcP27DJ2H1w34BVAvyMXUFgrqkn6DSCbyj3QpMSjSITc03cDuikWBJ5tkTCWOlq8Pppzgei45JP /wbwkXmOy3tmqq3SolGFRHD4XiZorMFupNhOf/zWgLuXyADdQ5AByvDwkxr8PYYIDK/dB70KhO1 gXu9B9AlAYQgVqV7HJlQGJoCm5vfpiiQ1TnPutvDGVzHta0xNuZzUaHr0bObkg5tN+mJ69nfIlJ iYy3FIkCKQooHQ793iPYoU4HCG0= X-Google-Smtp-Source: AGHT+IE1ktsQk+zigft2AbEnrcSeoezp9NdMguA2mYj3pzL7TfrhYwh2aC4uv57YfMhadzQlNgkdMg== X-Received: by 2002:a05:6a21:3a86:b0:1e0:daa9:46e4 with SMTP id adf61e73a8af0-1e0e0c031aemr3090937637.46.1732677678604; Tue, 26 Nov 2024 19:21:18 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-724e3e636ecsm8752899b3a.192.2024.11.26.19.21.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Nov 2024 19:21:18 -0800 (PST) Date: Tue, 26 Nov 2024 19:21:13 -0800 From: Stephen Hemminger To: Jie Hai Cc: , , , , Yisen Zhuang , "Wei Hu (Xavier)" , "Min Hu (Connor)" , , , Subject: Re: [PATCH v3 3/3] net/hns3: fix Rx packet without CRC data Message-ID: <20241126192113.3816193c@hermes.local> In-Reply-To: <5e373805-43d5-77c9-70d8-80e464387d49@huawei.com> References: <20240206011030.2007689-1-haijie1@huawei.com> <20240719090415.1513301-1-haijie1@huawei.com> <20240719090415.1513301-4-haijie1@huawei.com> <20241126161637.4d37c237@hermes.local> <5e373805-43d5-77c9-70d8-80e464387d49@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Wed, 27 Nov 2024 10:32:24 +0800 Jie Hai wrote: > On 2024/11/27 8:16, Stephen Hemminger wrote: > > On Fri, 19 Jul 2024 17:04:15 +0800 > > Jie Hai wrote: > > > >> From: Dengdui Huang > >> > >> When KEEP_CRC offload is enabled, the CRC data is still stripped > >> in following cases: > >> 1. For HIP08 network engine, the packet type is TCP and the length > >> is less than or equal to 60B. > >> 2. For HIP09 network engine, the packet type is IP and the length > >> is less than or equal to 60B. > >> > >> So driver has to recaculate packet CRC for this rare scenarios. > >> > >> In addition, to avoid impacting performance, KEEP_CRC is not > >> supported when NEON or SVE algorithm is used. > >> > >> Fixes: 8973d7c4ca12 ("net/hns3: support keeping CRC") > >> Cc: stable@dpdk.org > >> > >> Signed-off-by: Dengdui Huang > >> Acked-by: Huisong Li > >> Acked-by: Jie Hai > > > > Changed my mind on these patches after digging deeper into > > what other drivers are doing. The proposed patches for hns3 do > > the opposite of what the consensus of drivers is. > > > > When looking at internals, all other drivers do not include the CRC > > in the packet length calculation. It is hard to go back and determine > > the rational for this, but my assumption is that if a packet is received > > (with KEEP_CRC enabled), the application will likely want to send that > > packet to another location, and the transmit side doesn't want the CRC. > > > > There are a couple of related driver bugs in some drivers in handling > > of the flag as well. One driver (idpf) thinks the CRC should count for the byte > > statistics. This should be clarified and fixed. > > > > One driver (atlantic) adds a check but doesn't implement the flag; the check for > > valid offload flags is already handled by ethdev API. > > > > Please resubmit for a later release, and can be picked up then by 24.11 stable. > > > There is indeed much work to be done to clarify the relationship between > keep crc and fields in mbuf. > In the current patchset, patch 1 and patch 2 are used for this purpose, > but a bug occurs. > If CRC is not processed in the TX direction, CRC is forwarded as packet > data. > As a result, the packet length is increased by 4. > I agree that this part should be carefully investigated before a > decision is made. > > But for patch 3, this is a serious bug of the hns3 driver and and is > irrelevant to the preceding questions. > > Could you please apply the patch 3 first to fix the bug of hns3 ? > I can send a single patch of hns3 driver for the next version. > > > You have found an area of DPDK which is poorly documented. Will raise an > > agenda at next techboard to get a final agreement, then put that into > > the programmer's guide. > > . Yes a bugfix that makes hns3 behave like other drivers for now would be best approach.