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 9AE5443AD8; Tue, 20 Feb 2024 04:59:03 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6376D4029B; Tue, 20 Feb 2024 04:59:03 +0100 (CET) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id 4311A40289 for ; Tue, 20 Feb 2024 04:59:02 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Tf5FH24BCz1h0FJ; Tue, 20 Feb 2024 11:56:51 +0800 (CST) Received: from kwepemd100004.china.huawei.com (unknown [7.221.188.31]) by mail.maildlp.com (Postfix) with ESMTPS id CB64E1400DB; Tue, 20 Feb 2024 11:58:58 +0800 (CST) Received: from [10.67.121.175] (10.67.121.175) by kwepemd100004.china.huawei.com (7.221.188.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1258.28; Tue, 20 Feb 2024 11:58:58 +0800 Message-ID: <7438563e-c7b4-6e13-68bf-74ff423546af@huawei.com> Date: Tue, 20 Feb 2024 11:58:57 +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] net/hns3: fix Rx packet truncation when KEEP CRC enabled To: Ferruh Yigit , CC: , , , References: <20240206011030.2007689-1-haijie1@huawei.com> <11b8feac-4a9e-4d2c-8995-ed492d684750@amd.com> From: Jie Hai In-Reply-To: <11b8feac-4a9e-4d2c-8995-ed492d684750@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.175] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemd100004.china.huawei.com (7.221.188.31) 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 Hi, Ferruh, Thanks for your review. On 2024/2/7 22:15, Ferruh Yigit wrote: > On 2/6/2024 1:10 AM, Jie Hai wrote: >> From: Dengdui Huang >> >> When KEEP_CRC offload is enabled, some packets will be truncated and >> the CRC is still be stripped in following cases: >> 1. For HIP08 hardware, the packet type is TCP and the length >> is less than or equal to 60B. >> 2. For other hardwares, the packet type is IP and the length >> is less than or equal to 60B. >> > > If a device doesn't support the offload by some packets, it can be > option to disable offload for that device, instead of calculating it in > software and append it. The KEEP CRC feature of hns3 is faulty only in the specific packet type and small packet(<60B) case. What's more, the small ethernet packet is not common. > Unless you have a specific usecase, or requirement to support the offload. Yes, some users of hns3 are already using this feature. So we cannot drop this offload > <...> > >> @@ -2492,10 +2544,16 @@ hns3_recv_pkts_simple(void *rx_queue, >> goto pkt_err; >> >> rxm->packet_type = hns3_rx_calc_ptype(rxq, l234_info, ol_info); >> - >> if (rxm->packet_type == RTE_PTYPE_L2_ETHER_TIMESYNC) >> rxm->ol_flags |= RTE_MBUF_F_RX_IEEE1588_PTP; >> >> + if (unlikely(rxq->crc_len > 0)) { >> + if (hns3_need_recalculate_crc(rxq, rxm)) >> + hns3_recalculate_crc(rxq, rxm); >> + rxm->pkt_len -= rxq->crc_len; >> + rxm->data_len -= rxq->crc_len; >> > > Removing 'crc_len' from 'mbuf->pkt_len' & 'mbuf->data_len' is > practically same as stripping CRC. > > We don't count CRC length in the statistics, but it should be accessible > in the payload by the user. Our drivers are behaving exactly as you say. > > .