From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50089.outbound.protection.outlook.com [40.107.5.89]) by dpdk.org (Postfix) with ESMTP id B61F02965 for ; Thu, 29 Mar 2018 07:38:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EcjdHpCGzixD7ZqHfl9xI0uFfs4JF2dt6iWR4cp6LIM=; b=DX0iBq9QbkZUcX/pysM+jQmoJqLaC9d30+tzLJhDu3Zpzid7X+MwyslZoH+fjvxaX2d3Zl2BGUgiXLXnFRUyeKtPv/I72eCLZ4luZIu28Yq8N1Jl9IifQkPKgqGnY63/IPPUeeg8OCmCO0zmXCz2thi5uxW4oH375eac36gNhaA= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4458.eurprd05.prod.outlook.com (52.134.109.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Thu, 29 Mar 2018 05:38:02 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::808d:386e:26f3:859f]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::808d:386e:26f3:859f%13]) with mapi id 15.20.0609.012; Thu, 29 Mar 2018 05:38:02 +0000 From: Shahaf Shuler To: Ferruh Yigit , Neil Horman , John McNamara , "Marko Kovacevic" , Thomas Monjalon CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 2/2] ethdev: add new offload flag to keep CRC Thread-Index: AQHTwU1/hNXoD8tBSUa7uxbLa/b6daPmuOag Date: Thu, 29 Mar 2018 05:38:02 +0000 Message-ID: References: <20180320112631.107105-1-ferruh.yigit@intel.com> <20180321194730.52068-1-ferruh.yigit@intel.com> <20180321194730.52068-2-ferruh.yigit@intel.com> In-Reply-To: <20180321194730.52068-2-ferruh.yigit@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [31.154.10.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4458; 7:oJ8mPnSJngX7OhOKEZc1u837Js1q2NdXuUesdS2N8wCyVxHVVD2T55aqvdmk7M0ZpR2Sv2BoMv93im75ADcQVa0wUjyuy/uXDQmgUfwHCMwSLhOFiZ1yqxfYN/41E8g8cW2R0u3VqwpV/AXuF+e0wblBnQys9XG+oxZ2EQG5bQ5sr7fV7JvgNeWfzLdxuPf9t5s29Yfq7fhWSyELWqYbmKG/T+b/t+ovEb9knMsPJr69/xklTh/+cqj1JAJRScFO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3cc5e2a6-3a12-402a-9821-08d595373d02 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4458; x-ms-traffictypediagnostic: DB7PR05MB4458: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DB7PR05MB4458; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4458; x-forefront-prvs: 0626C21B10 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(189003)(199004)(25786009)(99286004)(14454004)(2906002)(5660300001)(86362001)(229853002)(575784001)(7736002)(7696005)(6436002)(105586002)(59450400001)(305945005)(76176011)(2900100001)(106356001)(33656002)(74316002)(6246003)(5250100002)(68736007)(186003)(8676002)(81166006)(6116002)(53936002)(3846002)(11346002)(4326008)(97736004)(26005)(486005)(486005)(476003)(102836004)(9686003)(6506007)(110136005)(66066001)(3280700002)(316002)(478600001)(8936002)(446003)(3660700001)(55016002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4458; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2MBKo1euwQaaBl8PCgW5S8sY+Gt1mS22V+04awXM6H4JmivzfS4MQh8vhzUeIFz+9eL+iuZ+VggpVEDRXBQUtSoyad8ZTtFIVnFn5H/y2DxoyVZAb0NGUPaMh34QMKe7cmOsTL3E8KdHbB1AoT5IB34AiUCkwR86bo0CfGBC35TFOcSnWF723BSoq2pKIrM4zuwJ0yXBZWDgRxmOznQ5/+HqiPlQWXUY7lEuMc4HfO2c4zxE+jJz4ghPvlE8tj4Yxbvi0utuXcZPTdqfhEzoOM5eDVaAWdYbRQ+FQmWIWE1WwQ71dkc+SPSSpDFDn2lbAa+ZWrdQnhCikLPIHuX6zA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3cc5e2a6-3a12-402a-9821-08d595373d02 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2018 05:38:02.0863 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4458 Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: add new offload flag to keep CRC X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 05:38:05 -0000 Wednesday, March 21, 2018 9:48 PM, Ferruh Yigit: > DEV_RX_OFFLOAD_KEEP_CRC offload flag added. >=20 > DEV_RX_OFFLOAD_CRC_STRIP flag will remain one more release but default > behavior in PMDs is to strip the CRC independent from this flag. >=20 > Until DEV_RX_OFFLOAD_CRC_STRIP flag is removed: > - Setting both KEEP_CRC & CRC_STRIP is INVALID > - Setting only CRC_STRIP PMD should strip the CRC > - Setting only KEEP_CRC PMD should keep the CRC > - Not setting both PMD should strip the CRC We cannot have such default behavior, it may break existing applications. The API of ethdev offloads says (even though it is not well documented) : = DEV_RX_OFFLOAD_CRC_STRIP (emphasis the STRIP).=20 meaning, if set -> STRIP, if not set -> don't strip. I am aware to at leas= t one application which wants to have the CRC, and for that purpose it natu= rally don't set the offload flag.=20 The fact some PMDs lack the ability to toggle the CRC stripping should be e= xposed in the "limitations" section of their related guide.=20 Up to here, this is the behavior as defined by the API.=20 Now, we want to change it, and I think it makes sense. However I think we s= hould take similar approach to what we did with the ethdev offloads API: 1. at first stage a new offload flag is exposed DEV_RX_OFFLOAD_KEEP_CRC and= implemented on the PMDs.=20 2. there is a conversion function on ethdev. Which for example converts ~DE= V_RX_OFFLOAD_CRC_STRIP -> DEV_RX_OFFLOAD_KEEP_CRC for the PMDs. 3. deprecation of DEV_RX_OFFLOAD_CRC_STRIP for applications and remove of t= he conversion functions.=20 More below, >=20 > Signed-off-by: Ferruh Yigit > --- > lib/librte_ether/rte_ethdev.h | 3 +++ > 1 file changed, 3 insertions(+) >=20 > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.= h > index 5e13dca6a..ab1030d42 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -939,6 +939,9 @@ struct rte_eth_conf { > #define DEV_RX_OFFLOAD_SCATTER 0x00002000 > #define DEV_RX_OFFLOAD_TIMESTAMP 0x00004000 > #define DEV_RX_OFFLOAD_SECURITY 0x00008000 > +/* Invalid to set both DEV_RX_OFFLOAD_CRC_STRIP and > +DEV_RX_OFFLOAD_KEEP_CRC > + * No DEV_RX_OFFLOAD_CRC_STRIP flag means stripping CRC */ > +#define DEV_RX_OFFLOAD_KEEP_CRC 0x00010000 Need also comment on DEV_RX_OFFLOAD_CRC_STRIP to say it is deprecated. > #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | > \ > DEV_RX_OFFLOAD_UDP_CKSUM | \ > DEV_RX_OFFLOAD_TCP_CKSUM) > -- > 2.13.6