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 DB7B145D76; Wed, 27 Nov 2024 03:32:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B0D414027A; Wed, 27 Nov 2024 03:32:29 +0100 (CET) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id ABC0D4026C for ; Wed, 27 Nov 2024 03:32:27 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Xyk1j6mhLz2GbvJ; Wed, 27 Nov 2024 10:30:17 +0800 (CST) Received: from kwepemf500004.china.huawei.com (unknown [7.202.181.242]) by mail.maildlp.com (Postfix) with ESMTPS id 6EAA8140118; Wed, 27 Nov 2024 10:32:25 +0800 (CST) Received: from [10.67.121.175] (10.67.121.175) by kwepemf500004.china.huawei.com (7.202.181.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 27 Nov 2024 10:32:24 +0800 Message-ID: <5e373805-43d5-77c9-70d8-80e464387d49@huawei.com> Date: Wed, 27 Nov 2024 10:32:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v3 3/3] net/hns3: fix Rx packet without CRC data To: Stephen Hemminger CC: , , , , Yisen Zhuang , "Wei Hu (Xavier)" , "Min Hu (Connor)" , , , References: <20240206011030.2007689-1-haijie1@huawei.com> <20240719090415.1513301-1-haijie1@huawei.com> <20240719090415.1513301-4-haijie1@huawei.com> <20241126161637.4d37c237@hermes.local> From: Jie Hai In-Reply-To: <20241126161637.4d37c237@hermes.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.175] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemf500004.china.huawei.com (7.202.181.242) 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 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. > .