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 09D9DA034F; Mon, 22 Mar 2021 12:38:27 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5FABE40040; Mon, 22 Mar 2021 12:38: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 8326C4003D for ; Mon, 22 Mar 2021 12:38:26 +0100 (CET) Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4F3ssY047fzkdD5; Mon, 22 Mar 2021 19:36:49 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Mon, 22 Mar 2021 19:38:21 +0800 To: Ferruh Yigit , Lance Richardson , Stephen Hemminger CC: "dev@dpdk.org" , Thomas Monjalon , Andrew Rybchenko References: <3ddef567-d7ee-5364-cf42-81118a7153ee@huawei.com> <20210319090653.22b430ea@hermes.local> <9d792e8a-6af5-f4bc-c311-35d58075a4ba@intel.com> From: "Min Hu (Connor)" Message-ID: Date: Mon, 22 Mar 2021 19:38:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <9d792e8a-6af5-f4bc-c311-35d58075a4ba@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.128] X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] Questions about keeping CRC 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 Sender: "dev" Hi, Lance ,Stephen and Ferruh, Got it, thanks for your reply. 在 2021/3/22 18:53, Ferruh Yigit 写道: > On 3/19/2021 5:02 PM, Lance Richardson wrote: >> On Fri, Mar 19, 2021 at 12:07 PM Stephen Hemminger >> wrote: >>> >>> On Fri, 19 Mar 2021 20:13:20 +0800 >>> "Min Hu (Connor)" wrote: >>> >>>> Hi, all, >>>>        DPDK has introduced one offload: DEV_RX_OFFLOAD_KEEP_CRC. It >>>> means that >>>> the device has the ablility of keeping CRC（four bytes at the end of >>>> packet）of packet in RX. >>>>        In common scenarios, When one packet enter into NIC device, NIC >>>> will check the CRC and then strip the CRC，at last send the packet into >>>> the buffer. >>>>        So my question is: >>>>         why the DEV_RX_OFFLOAD_KEEP_CRC is introduced into DPDK?  I >>>> think that >>>> when the packet enter into the NIC, the CRC will has no significance to >>>> APP. Or is there any scenarios that CRC is useful for APP？ >>>>        Thanks for your reply. >>> >>> Your right it doesn't make sense for almost all applications. Maybe >>> an application >>> testing for bad NIC hardware might use it. >>> >>> It is one of those features introduced in DPDK because "our hardware >>> can do it, >>> therefore it ought to be exposed in DPDK API"... >> >> The only use case I have seen was in L2 forwarding applications which >> would >> receive packets with CRC preserved and then transmit them with an >> indication >> to the NIC that the CRC should not be regenerated. The idea was that >> if the >> packet was corrupted anywhere in the system (e.g. by a memory error), it >> could be detected at the receiver. Of course DPDK doesn't have the notion >> of transmitting a packet without regenerating the CRC, so that use case >> doesn't seem to apply here. >> >> I think that DEV_RX_OFFLOAD_KEEP_CRC is not likely to be useful, but >> I would be interested in hearing otherwise. I happen to know of at >> least one >> PMD that advertises this ability but doesn't actually behave any >> differently >> when it is enabled. >> > > I think it is more like Stephen said, some HW supports it and software > is enabling it. It shouldn't hurt the PMD/HW that doesn't support this. > .