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 5BD2CA0545; Tue, 11 Oct 2022 13:55:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 165AA42DB3; Tue, 11 Oct 2022 13:55:51 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id F3D7D42D7E for ; Tue, 11 Oct 2022 13:55:49 +0200 (CEST) Received: from [192.168.10.54] (unknown [37.252.90.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id 717B9E0476; Tue, 11 Oct 2022 15:55:49 +0400 (+04) Message-ID: <2f221574-ac04-2931-275b-e758669e0bef@arknetworks.am> Date: Tue, 11 Oct 2022 15:54:47 +0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: CRC offload from application's POV Content-Language: en-US To: Ferruh Yigit Cc: Denis Pryazhennikov , dev@dpdk.org References: <11b33bf3-413a-6955-423a-cc47a73e2202@arknetworks.am> <103627bd-d704-84a2-9f3e-5e4a7341e6a7@amd.com> From: Viacheslav Galaktionov In-Reply-To: <103627bd-d704-84a2-9f3e-5e4a7341e6a7@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 10/11/22 15:36, Ferruh Yigit wrote: > On 10/11/2022 11:48 AM, Viacheslav Galaktionov wrote: >> Hi! >> >> We're looking to implement CRC offload in our driver and we're having >> difficulties understanding what >> the feature changes from the application's point of view. If we >> enable the KEEP_CRC offload, then the >> NIC is supposed to preserve the CRC in the packet, that much is >> clear. But we checked other drivers >> and it seems common for PMDs to remove the CRC from the final mbufs. >> Why is that? >> >> We couldn't find any place where the CRC would be stored after >> removal, so it looks like the application >> doesn't have access to this piece of data. And if so, what's the >> point of having this feature if the CRC >> is discarded either way? >> >> We're probably missing something and would really appreciate any help >> with this. >> > > Hi Viacheslav, > > As you said default behavior is to strip the CRC from packet, even > some devices doesn't support having CRC in the packet it is removed by > HW automatically. In this case application can't access to the CRC. > > For the devices that has capability to keep CRC, KEEP_CRC offload > should enable having CRC as part of the packet. There is no special > field to store the CRC. > I'm asking because I'm seeing a common pattern in the code base: if the hardware didn't remove the CRC, the driver does this itself. Grepping the code for "crc_len" will show you what I mean. One of the most apparent examples of this happening can be seen in drivers/net/e1000/em_rxtx.c: /*  * This is the last buffer of the received packet.  * If the CRC is not stripped by the hardware:  *   - Subtract the CRC    length from the total packet length.  *   - If the last buffer only contains the whole CRC or a part  *     of it, free the mbuf associated to the last buffer.  *     If part of the CRC is also contained in the previous  *     mbuf, subtract the length of that CRC part from the  *     data length of the previous mbuf.  */ I don't understand why this is necessary, and whether this is just a particularity of this driver or how the feature is supposed to be implemented everywhere. I haven't checked every driver, but it seems like a lot of them do something similar to this.