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 B8510A0545;
	Tue, 11 Oct 2022 12:50:00 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 8938842D38;
	Tue, 11 Oct 2022 12:49:59 +0200 (CEST)
Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80])
 by mails.dpdk.org (Postfix) with ESMTP id C177442D0C
 for <dev@dpdk.org>; Tue, 11 Oct 2022 12:49:58 +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 3EEABE002A;
 Tue, 11 Oct 2022 14:49:58 +0400 (+04)
Message-ID: <11b33bf3-413a-6955-423a-cc47a73e2202@arknetworks.am>
Date: Tue, 11 Oct 2022 14:48:59 +0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.2
Content-Language: en-US
To: dev@dpdk.org
From: Viacheslav Galaktionov <Viacheslav.Galaktionov@arknetworks.am>
Subject: CRC offload from application's POV
Cc: Denis Pryazhennikov <Denis.Pryazhennikov@arknetworks.am>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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

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.

Thank you in advance,
Viacheslav