From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0068.outbound.protection.outlook.com [104.47.0.68]) by dpdk.org (Postfix) with ESMTP id 21312374 for ; Thu, 29 Mar 2018 09:56:42 +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=AK5KrArRK/dCEV6IcMr0Tdp4Cq/kFjXStqtOXozampc=; b=NSPSzKzO8vyi+huX44Jmq5nOtQwSSZORu3S5kzjAet6mYUeQscjMa9GWAFS42sgeA4aYbEtEeN3wcosT/vxQcG7T8kyasnn+xw9jzKn/7eCwVmPD0dGSe5rpHsg7v2Pn9GED30dfmW140ZN4q++vgmgsVtkTx4xMzIjumSpcRC4= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4409.eurprd05.prod.outlook.com (52.134.109.10) 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 07:56:40 +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 07:56:40 +0000 From: Shahaf Shuler To: Thomas Monjalon CC: Ferruh Yigit , Neil Horman , John McNamara , "Marko Kovacevic" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 2/2] ethdev: add new offload flag to keep CRC Thread-Index: AQHTwU1/hNXoD8tBSUa7uxbLa/b6daPmuOaggAAnrACAAAMUgA== Date: Thu, 29 Mar 2018 07:56:40 +0000 Message-ID: References: <20180320112631.107105-1-ferruh.yigit@intel.com> <20180321194730.52068-2-ferruh.yigit@intel.com> <15555561.lU3UqzoiBB@xps> In-Reply-To: <15555561.lU3UqzoiBB@xps> 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; DB7PR05MB4409; 7:bjo0iqViBKMcvk1Rng81U92qT/ZUZCWOsqYuo03AyAU1tWw7h4ofl7kHOiogkGnEMG7bjYj+LNPdlfrqQZZcK+MInMsQ2fk26D3F47LREFOTsglXNIrjF7PtlQjgGF3JIpRI24KQOivexGUINUfdcjTGlCgcsSnoEEvvuAQ5EBKWs71PX+R1tvFaPK0s+5TA0YgMFY2ldKzij2/n7O90GT0k0LsjdKSNYNxVCGIQ3/kifgocHz4+Fgeti4ascsX2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d2921fdb-68c9-4fa9-db9e-08d5954a9b15 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4409; x-ms-traffictypediagnostic: DB7PR05MB4409: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB7PR05MB4409; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4409; x-forefront-prvs: 0626C21B10 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39380400002)(39860400002)(346002)(189003)(199004)(3660700001)(8936002)(33656002)(81156014)(5660300001)(14454004)(26005)(97736004)(478600001)(305945005)(105586002)(81166006)(8676002)(11346002)(54906003)(74316002)(2906002)(446003)(93886005)(486005)(486005)(5250100002)(316002)(6246003)(66066001)(102836004)(6116002)(6916009)(106356001)(53936002)(76176011)(3846002)(4326008)(7696005)(55016002)(25786009)(229853002)(86362001)(68736007)(6436002)(2900100001)(6506007)(99286004)(7736002)(186003)(3280700002)(476003)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4409; 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: m8EiMPBcO7kE3/H5UNiQLpJJHaVvpuRRQfmHQKuxANB88NkS/mYrA+rW8bWHjguBXnviY5JlyzD26Cio+j/F6smjyVJvhGhlx5v67fhBSzZRFHwTbMMhXkrwF5wqJT2xVRUZwLzkUT24dFlY5GhRoLW2k1iFQspiHZPtdT1U21HZdZMEBO8wSjyGBVEpNDg/kwRUrVmTfNVD8vSAN/EO5vt3N7u/ripxVMisWWWfGXlUMrCwYI0hnzJ6TYr4SYVyvmA4RNHRgtu5OCIHGth4vD7ChNy9LRs2paLqaJMUIcZQxkqDCdQgAJHLESHCGTBxaoQ5wKuQWNtymY32tRU4Fg== 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: d2921fdb-68c9-4fa9-db9e-08d5954a9b15 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2018 07:56:40.3406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4409 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 07:56:42 -0000 Thursday, March 29, 2018 10:43 AM, Thomas Monjalon: > 29/03/2018 07:38, Shahaf Shuler: > > Wednesday, March 21, 2018 9:48 PM, Ferruh Yigit: > > > DEV_RX_OFFLOAD_KEEP_CRC offload flag added. > > > > > > DEV_RX_OFFLOAD_CRC_STRIP flag will remain one more release but > > > default behavior in PMDs is to strip the CRC independent from this fl= ag. > > > > > > 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 application= s. > > > > The API of ethdev offloads says (even though it is not well documented)= : > DEV_RX_OFFLOAD_CRC_STRIP (emphasis the STRIP). > > meaning, if set -> STRIP, if not set -> don't strip. I am aware to at = least one > application which wants to have the CRC, and for that purpose it naturall= y > don't set the offload flag. > > > > The fact some PMDs lack the ability to toggle the CRC stripping should = be > exposed in the "limitations" section of their related guide. > > > > Up to here, this is the behavior as defined by the API. > > > > Now, we want to change it, and I think it makes sense. However I think = we > should 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 > This is what is proposed above, except that we change the default > behaviour. > If we introduce a new flag which is the contrary of the old one, we need = to > choose which one is the default, so which one has no effect. The default behavior should remain as long as we don't deprecate the DEV_RX= _OFFLOAD_CRC_STRIP flag. Logic should be : Until DEV_RX_OFFLOAD_CRC_STRIP flag is removed: - Setting both KEEP_CRC & CRC_STRIP is INVALID - enforced by ethdev.=20 - Setting only CRC_STRIP PMD should strip the CRC - Setting only KEEP_CRC PMD should keep the CRC - Not setting both PMD should *not* strip the CRC=20 >=20 > > 2. there is a conversion function on ethdev. Which for example converts > ~DEV_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 the conversion functions. >=20 >=20 >=20