From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1B35845DD2;
	Sat, 30 Nov 2024 03:26:28 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id AB3BE4027D;
	Sat, 30 Nov 2024 03:26:27 +0100 (CET)
Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32])
 by mails.dpdk.org (Postfix) with ESMTP id 992A440150
 for <dev@dpdk.org>; Sat, 30 Nov 2024 03:26:25 +0100 (CET)
Received: from mail.maildlp.com (unknown [172.19.162.112])
 by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Y0Yp54B8nz1yqxB;
 Sat, 30 Nov 2024 10:26:37 +0800 (CST)
Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84])
 by mail.maildlp.com (Postfix) with ESMTPS id C750C1402DA;
 Sat, 30 Nov 2024 10:26:22 +0800 (CST)
Received: from [10.67.121.193] (10.67.121.193) by
 dggpeml500011.china.huawei.com (7.185.36.84) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2507.39; Sat, 30 Nov 2024 10:26:22 +0800
Message-ID: <b77aaaaf-4fb3-4e50-9da9-b3556b66be5d@huawei.com>
Date: Sat, 30 Nov 2024 10:26:22 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] net/hns3: fix Rx packet without CRC data
Content-Language: en-US
To: Stephen Hemminger <stephen@networkplumber.org>, Jie Hai
 <haijie1@huawei.com>
CC: <dev@dpdk.org>, <thomas@monjalon.net>, <ferruh.yigit@amd.com>, Wathsala
 Vithanage <wathsala.vithanage@arm.com>, <lihuisong@huawei.com>,
 <fengchengwen@huawei.com>
References: <20240206011030.2007689-1-haijie1@huawei.com>
 <20241127100807.683461-1-haijie1@huawei.com>
 <4a5fa848-e4f4-33ab-5806-ad90ddad9d3f@huawei.com>
 <20241129091206.02a39633@hermes.local>
From: huangdengdui <huangdengdui@huawei.com>
In-Reply-To: <20241129091206.02a39633@hermes.local>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.67.121.193]
X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To
 dggpeml500011.china.huawei.com (7.185.36.84)
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org


On 2024/11/30 1:12, Stephen Hemminger wrote:
> On Fri, 29 Nov 2024 09:36:43 +0800
> Jie Hai <haijie1@huawei.com> wrote:
> 
>>> +
>>> +static inline void
>>> +hns3_recalculate_crc(struct rte_mbuf *m)
>>> +{
>>> +	char *append_data;
>>> +	uint32_t crc;
>>> +
>>> +	crc = rte_net_crc_calc(rte_pktmbuf_mtod(m, void *),
>>> +			       m->data_len, RTE_NET_CRC32_ETH);
>>> +
>>> +	/*
>>> +	 * After CRC is stripped by hardware, pkt_len and data_len do not
>>> +	 * contain the CRC length. Therefore, after CRC data is appended
>>> +	 * by PMD again.
>>> +	 */
>>> +	append_data = rte_pktmbuf_append(m, RTE_ETHER_CRC_LEN);
>>> +
>>> +	/* CRC data is binary data and does not care about the byte order. */
>>> +	memcpy(append_data, &crc, RTE_ETHER_CRC_LEN);
>>> +}
> 
> As mentioned previously.
> Including CRC in the packet length (pkt_len and data_len) is not the
> current behavior of most drivers. Therefore hns3 should follow the precedent
> of other drivers and put it past the data.

Yes. This patch does not change the original behavior.
In subsequent processing, crc_len is deducted from pkt_len and data_len.

> 
> In the future the KEEP_CRC flag needs more work to be useable. It needs
> documentation and flag in mbuf (similar to hash and checksum) so that application
> can no that it is present and valid.
> 
> Please resend the patch as a bugfix that puts crc after the data.