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 CB092A034F; Mon, 22 Mar 2021 11:53:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8069940042; Mon, 22 Mar 2021 11:53:39 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id E62AD40040 for <dev@dpdk.org>; Mon, 22 Mar 2021 11:53:37 +0100 (CET) IronPort-SDR: O8njQu9htIIqyX/uzJwvczb1h6xemB7WquroBxrO3Vtn2ilmB3QBxCCBkPI8y1W85G56Tbkis4 4/DltZZwoctw== X-IronPort-AV: E=McAfee;i="6000,8403,9930"; a="177819715" X-IronPort-AV: E=Sophos;i="5.81,268,1610438400"; d="scan'208";a="177819715" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2021 03:53:36 -0700 IronPort-SDR: dD82jYt5mBHuEvNIZUVaLf7gtWkvHFBc3F+TuvvyfT8phAtqQKac/IsFU7e/cu7etDY40+VuA4 iUFVmlS3HhPA== X-IronPort-AV: E=Sophos;i="5.81,268,1610438400"; d="scan'208";a="451695073" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.14.44]) ([10.252.14.44]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2021 03:53:35 -0700 To: Lance Richardson <lance.richardson@broadcom.com>, Stephen Hemminger <stephen@networkplumber.org> Cc: "Min Hu (Connor)" <humin29@huawei.com>, "dev@dpdk.org" <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> References: <3ddef567-d7ee-5364-cf42-81118a7153ee@huawei.com> <20210319090653.22b430ea@hermes.local> <CADyeNEDhnk=Ntg_0Dni+nC9MFGm-CgCCQzT5y9vjJ0-g1CxTew@mail.gmail.com> From: Ferruh Yigit <ferruh.yigit@intel.com> X-User: ferruhy Message-ID: <9d792e8a-6af5-f4bc-c311-35d58075a4ba@intel.com> Date: Mon, 22 Mar 2021 10:53:31 +0000 MIME-Version: 1.0 In-Reply-To: <CADyeNEDhnk=Ntg_0Dni+nC9MFGm-CgCCQzT5y9vjJ0-g1CxTew@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 <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 Sender: "dev" <dev-bounces@dpdk.org> On 3/19/2021 5:02 PM, Lance Richardson wrote: > On Fri, Mar 19, 2021 at 12:07 PM Stephen Hemminger > <stephen@networkplumber.org> wrote: >> >> On Fri, 19 Mar 2021 20:13:20 +0800 >> "Min Hu (Connor)" <humin29@huawei.com> 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.