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 68CBFA0524;
	Fri, 19 Mar 2021 17:07:04 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id DE227140FE5;
	Fri, 19 Mar 2021 17:07:03 +0100 (CET)
Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com
 [209.85.210.177])
 by mails.dpdk.org (Postfix) with ESMTP id 5177E140FDC
 for <dev@dpdk.org>; Fri, 19 Mar 2021 17:07:02 +0100 (CET)
Received: by mail-pf1-f177.google.com with SMTP id g15so6220901pfq.3
 for <dev@dpdk.org>; Fri, 19 Mar 2021 09:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20150623.gappssmtp.com; s=20150623;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=dvUScIokiX8B8LfGwpKeI941w73oj/75cK2g8hII3T0=;
 b=ilsWxDnO67NGqC6oZwssUkUKxOtxZPxr5HsSviX1gn6Om/l4j1M/0cK+pfaTJAD/U2
 KQMdoxLGiDU5PiwKGbs28+zRop/NrCEhl0obhV9otOzp+c4Vu73bYRiL/w2z2Xcmrm/r
 S3S7kcueA7rl6i01WLd7VSot9rzzC626HoxhVqr4hHGYQWygFjaymCFJ9FyhxzvCjBEj
 qx7TO80qTIQHGW0COCCabJ5+fkfrJpxalZtcQgyFDPtFZqX7yXK6mgUIpJhax8O4W/rZ
 62oyAgg4/f1vGEgfS9kYxpWcatfSlNLaadQmrzybBhHhBAF4F46MM7ZbgT1EF1Q4NBuQ
 UCnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=dvUScIokiX8B8LfGwpKeI941w73oj/75cK2g8hII3T0=;
 b=PsfIVrD3JIQmEIY99KS43gi7GU7O/lZV3vq54U5e+N3m9cqRYxmGrYsAbPvCvoODD9
 lpLyEgbUQMG+kVAZuf0bGtNGTkkyIegFkO0aRpkVuyFN2uaoKmU0FEVbL0zcX5cc1iA1
 2MJ9tamCvxO9TPGjZdq4FAh/01rmU2JECibeFYvqjlnEfB1jDFy+iydotAsZTLe7XDew
 1GdqfNyOan5b9LEqT6fKiBszzymVeI0uNIxpKk6ASeByRFirjct5YaD22nIindxfBVVF
 fnazBFK03oDlRgMm9knQX5X+qOQm4Sg0YZW9xq3myae4Li+dmQ5ncNSPqDYnOfPKF2X/
 TaEw==
X-Gm-Message-State: AOAM530xFwZ89yR3F8EeSoa//MJZYe8xvDtOCXVVAC5TL3FD+54gpwd3
 vGS69YyuM6cQGNoeWLBw7Z8YRg==
X-Google-Smtp-Source: ABdhPJzduO7ww3Ohm2jyKOxF6YlSH5w8assDg0y0iho1plcW/Rxa9KdHEF7/5WkYRLLFc6SqePkktw==
X-Received: by 2002:a62:3646:0:b029:205:2117:f339 with SMTP id
 d67-20020a6236460000b02902052117f339mr9711976pfa.32.1616170021348; 
 Fri, 19 Mar 2021 09:07:01 -0700 (PDT)
Received: from hermes.local (76-14-218-44.or.wavecable.com. [76.14.218.44])
 by smtp.gmail.com with ESMTPSA id y15sm6735368pgi.31.2021.03.19.09.07.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 19 Mar 2021 09:07:01 -0700 (PDT)
Date: Fri, 19 Mar 2021 09:06:53 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Min Hu (Connor)" <humin29@huawei.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Ferruh Yigit <ferruh.yigit@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>
Message-ID: <20210319090653.22b430ea@hermes.local>
In-Reply-To: <3ddef567-d7ee-5364-cf42-81118a7153ee@huawei.com>
References: <3ddef567-d7ee-5364-cf42-81118a7153ee@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 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=
=20
> the device has the ablility of keeping CRC=EF=BC=88four bytes at the end =
of=20
> packet=EF=BC=89of packet in RX.
> 	In common scenarios, When one packet enter into NIC device, NIC
> will check the CRC and then strip the CRC=EF=BC=8Cat last send the packet=
 into=20
> the buffer.
> 	So my question is:
> 	 why the DEV_RX_OFFLOAD_KEEP_CRC is introduced into DPDK?  I think that=
=20
> when the packet enter into the NIC, the CRC will has no significance to=20
> APP. Or is there any scenarios that CRC is useful for APP=EF=BC=9F
> 	Thanks for your reply.

Your right it doesn't make sense for almost all applications. Maybe an appl=
ication
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"...