From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3FF1DA00E6 for ; Fri, 9 Aug 2019 05:48:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3BDCA29CB; Fri, 9 Aug 2019 05:48:52 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 3AF25374 for ; Fri, 9 Aug 2019 05:48:50 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x793jtbJ001002; Thu, 8 Aug 2019 20:48:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=cRXBJ4RmfNxmMw2xS+W56P7+WQRolnnVqHSm0Fy7kP4=; b=QtaNYa5I/GoQZTaHv9xnt6gOpaAMKAbbFZiNl1223z6UsPKbve2ljeMf3BOz8zAxMeIb N1bI+ytdHjBS5xRFVY1qFA5MnNQr1aRoJPTFQqxRWdODqvE3kAtlV+R0KsPy3J+k2k6T WqcS9oMFaNHaWE/x7voCWUqGfON7aO7saBuS0cTQFsLhKcOGQRbkY09eTEEOGQf54amb LYQPQwJDnLygwoCK8UlnlK1JjtuNbyckoOYy2ormaXnU3vbsYm14dCCSo2rUEJgH5oZt MLPSvIKaob8YE6pHVQi00mBIqi98XDBVVO+6fx/CPVgh6Efr+0xR6UH6Ph+zTryU322Q TA== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2u59sm6ext-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Aug 2019 20:48:49 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 8 Aug 2019 20:48:47 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.58) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 8 Aug 2019 20:48:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EHvjFW2+nAEfbnH6HreXHu0eDlrg0saU44rOgDJ7GorxhNHRU5esRAxomZdYoDGjz2NnCETWKq2OYvhduN1HBLu5haQe69CLfaZ9OobSNiMpqlPVL+yQdV59CvtpcNkrVFexB6zJrKYudEyOvR5Yups+KWW67mSko2H6F7IFOzrdIiggcp/3cPp6cotoDZwgwTU4g+yvSOgcijvwNsz9jcS6gUQIBofcKWC4ZMxJw/2rH82/fmwzmHn3i8UJwvoh1i87oEsRXv5n8MPixG0xi8labs4lQJrW3naS+6VyPDkftEq3pMl1lAtbbQoCJl6Fdq7Kd8VbZLz9arWycPywBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cRXBJ4RmfNxmMw2xS+W56P7+WQRolnnVqHSm0Fy7kP4=; b=EOZiqFr1L8HZkv7hNZCxJ8uarwUehNpflD19drjDY6oFDCnoVwF2fBhsaJVp4Ij0supfS4qP1sfdf3HSb2soUeCXFn/Z+r7oyVoSUpx6wHY0jEf1zgUF5xFTbwa0QoMhuFGPTf5exOciSgBi6SDgazWkGIQ5QczbEJRSRLaXhckmbM3RwXjybkEEMDNWfbsJ9Lj1O06Z2j2KIWaYGGxdzA8wmBtyIURg7JYhSAoWd3Llu4GOgYP1En435vhh5i4KcmGr7BdvTttqB0sVZaAUzR0h0vhPgQ+eRF9JqqFyapDQuVmDRd/DMG31cK6bVAFGwqpmBlvZ7IizIjZhchik0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=marvell.com;dmarc=pass action=none header.from=marvell.com;dkim=pass header.d=marvell.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cRXBJ4RmfNxmMw2xS+W56P7+WQRolnnVqHSm0Fy7kP4=; b=ZDp2OPu72jd9baN7LZ9OA9yevf1R0IRFSfovSFQKpg1zn7zhMAvvT6RDoi796p5ZxoI2PsKp5iXpNECBwnLqzasYFwV/5zOa12O9PGfWO6eG41Aiv/P7a1GElq0DCq0LvCrNL3LsFoHHOFtTdRH6XBx/DG4d4xZUOZeR/ewOWus= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2920.namprd18.prod.outlook.com (20.179.59.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Fri, 9 Aug 2019 03:48:42 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::5877:72b7:40cf:2013]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::5877:72b7:40cf:2013%3]) with mapi id 15.20.2157.015; Fri, 9 Aug 2019 03:48:42 +0000 From: Jerin Jacob Kollanukkaran To: "Ananyev, Konstantin" , "Pavan Nikhilesh Bhagavatula" , "stephen@networkplumber.org" , "arybchenko@solarflare.com" , "hemant.agrawal@nxp.com" , "thomas@monjalon.net" , "Yigit, Ferruh" , "Richardson, Bruce" , Neil Horman , "Mcnamara, John" , "Kovacevic, Marko" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [patch v3] doc: announce API change in ethdev offload flags Thread-Index: AQHVTcr3n9J0wDDahEu40jmCmktW06bxAfswgAAE+QCAAAHmgIAABR0AgAABAzCAAGkiAIAArsKw Date: Fri, 9 Aug 2019 03:48:42 +0000 Message-ID: References: <20190808081752.516-1-pbhagavatula@marvell.com> <20190808085859.796-1-pbhagavatula@marvell.com> <2601191342CEEE43887BDE71AB9772580168A63989@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580168A639E4@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580168A63A1B@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580168A63C89@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580168A63C89@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.140.231.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9fbb576c-1b01-4d0b-1180-08d71c7c78e2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2920; x-ms-traffictypediagnostic: BYAPR18MB2920: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01244308DF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(39860400002)(136003)(366004)(376002)(199004)(13464003)(189003)(66446008)(8936002)(186003)(2501003)(446003)(7736002)(86362001)(74316002)(110136005)(81166006)(55016002)(305945005)(5660300002)(6116002)(81156014)(66476007)(476003)(6436002)(76116006)(33656002)(11346002)(229853002)(66556008)(316002)(66946007)(26005)(53936002)(3846002)(64756008)(9686003)(2906002)(99286004)(14444005)(25786009)(102836004)(52536014)(66066001)(71190400001)(7696005)(478600001)(486006)(55236004)(71200400001)(53546011)(4326008)(76176011)(14454004)(7416002)(6506007)(2201001)(256004)(6246003)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2920; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BKoZJL3yk3+nqaHBGB/p+GsS4XJ3OpZQVp5od1PLcP/TqeeBBDdPxz49Kvo8SdfrMBCSwMC3PxS1vmyQZc17l0Uy+WW3vnYJgxeqVJa86Tjhxz02/VNQ0FKNjkzCDH4HpHgjifGumAVo+bToJDdmpcWxnwLKjch5oMETTZlIGCUhCANIiepxQ1rrtuzagaj/SKI1zNdfJn5IJHyklNkoMTzDLI7VPCRPzrEH1LA/ASdnFFgDBHjoglUVquZaR/HvILvCSClpa2xsJX55KlO6ayXYjdxggJrRpdhr6IaHOyp3U8LGGIbqlUivoiOd6ZusmbbCSbewZrVePfsq4JMcypfOh45rV5gwcXvTQZxgKWj2vy71Q0YL4xRgNB+iheKZR4fTDjDJttIvKShDi8+IolyQ1/LRXhAla5osQ1WB0+A= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9fbb576c-1b01-4d0b-1180-08d71c7c78e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 03:48:42.3899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kD57vG8cIduyCkoSgeDQVXI8ndVS8CQgUyr+Ecu9rw752uvHWt8Nrbbq8Vu47ASUVXs3Ff+Pq8wGcckyazpgTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2920 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-09_01:2019-08-07,2019-08-09 signatures=0 Subject: Re: [dpdk-dev] [patch v3] doc: announce API change in ethdev offload flags 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Ananyev, Konstantin > Sent: Thursday, August 8, 2019 10:24 PM > To: Jerin Jacob Kollanukkaran ; Pavan Nikhilesh > Bhagavatula ; stephen@networkplumber.org; > arybchenko@solarflare.com; hemant.agrawal@nxp.com; > thomas@monjalon.net; Yigit, Ferruh ; Richardson, > Bruce ; Neil Horman > ; Mcnamara, John ; > Kovacevic, Marko > Cc: dev@dpdk.org > Subject: [EXT] RE: [dpdk-dev] [patch v3] doc: announce API change in ethd= ev > offload flags > > > > Since application has two knobs rte_eth_dev_get_supported_ptypes() > > > > and DEV_RX_OFFLOAD_PTYPE. We may not need to new ol_flags for > this > > > change. Right? > > > > i.e if application sets the DEV_RX_OFFLOAD_PTYPE, The application > > > > will get the parsed ptypes by the driver(=3D > > > rte_eth_dev_get_supported_ptypes()). > > > > So there is no scope ambiguity. Right? > > > > > > I still think there is: > > > Imagine user has 2 eth devices, one does support > > > DEV_RX_OFFLOAD_PTYPE, second doesn't. Now he has a mix of packets > > > from both devices, that you want t process. > > > How would he figure out for which of them ptype values are valid, > > > and for each are not? > > > Trace back from what port he has received them? > > > Not very convenient, and not always possible. > > > > I thought so. But in that case, application can always set > > DEV_RX_OFFLOAD_PTYPE Flags for all the ethdev ports. Right? Rather > > having any complicated ol_flags or port based parsing. If limit the > _contract_ to following, we are good. Right? > > # when DEV_RX_OFFLOAD_PTYPE is set, mbuf.packet_type will be valid > and > > mbuf.packet_type will have parsed packet type >=20 > Yes sure in principle user can calculate smallest common subset of RX > offloads supported by all devs in the system and use only them. > Then he can use some global value for ol_flags that will be setup at > initialization time, instead of checking ol_flags for every mbuf. > Though inside DPDK we don't use that method for other offloads (cksum, > vlan, rss). > Why we should do different here? I agree. We don't need to. > Again how to deal with hot-plugged devices with such approach? >=20 > > > > or the negative offload(This contract is pretty clear, I don't think > > any ambiguity at all) # when DEV_RX_OFFLOAD_NO_PTYPE(something > > similar) is set, mbuf.packet_type will be invalid. > > > > > I think we need either to introduce new ol_flag value (as we usually > > > do for other RX offloads), or force PMD to always set ptype value. > > > > Setting new ol_flag value may effect performance for existing drivers > > which don't planning to use this offload >=20 > If the driver doesn't support DEV_RX_OFFLOAD_PTYPE, it wouldn't need to > set anything (neither ol_flags, neither packet_type). Yes >=20 > > and it complicates the > > application to have additional check based on ol_flag. If you see any > > corner case with above section, > > > > How about just setting as ptype as 0 incase it is not parsed by driver. >=20 > As I said above - ok by me. > AFAIK, this is current behavior, so no changes in PMD will be required. >=20 > > Actual lookup is the costly one, writing 0 to pytpe is not costly as > > there are plenty of writes in Rx and it will be write merged(No CPU > > stall) >=20 > Yes packet_type is at first 64B, so shouldn't cause any extra overhead. >=20 > > > > I did not get the complete picture of > > "rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t > ptype_mask); instead of DEV_RX_OFFLOAD_PTYPE? scheme", Does it help? >=20 > I thought about it as just a different way to disable(/limit) requested b= y user > PTYPE support. > If let say user is not interested in ptype information at all, he can ask= PMD to > just always set ptype value to 0: > rte_eth_dev_set_supported_ptypes(port, RTE_PTYPE_UNKNOWN); >=20 > if he is interested just in L2/L3 layer info, he can ask PMD to provide p= type > information only for L2/L3: > rte_eth_dev_set_supported_ptypes(port, RTE_PTYPE_L2_MASK | > RTE_PTYPE_L3_MASK); >=20 > Or to enable all supported by PMD ptypes: > rte_eth_dev_set_supported_ptypes(port, UINT32_MAX) The API looks good to me. We need to document the rte_eth_dev_set_supporte= d_ptypes() must be called when device is in stop state to allow PMD do slow path conf= iguration. To summarize: Two options to control PTYPE lookup: Option 1: - If DEV_RX_OFFLOAD_PTYPE set, PMD returns mbuf->packet_type with rte_eth_d= ev_get_supported_ptypes() - If DEV_RX_OFFLOAD_PTYPE is not set, PMD still can return mbuf->packet_ty= pe with rte_eth_dev_get_supported_ptypes() But if PMD can do some optimization, it can avoid ptype lookup and return m= buf->packet_type as zero. Option 2: - Introduce rte_eth_dev_set_supported_ptypes(port, needed_ptypes). I think, rte_eth_dev_set_supported_ptypes() is better option As Konstantain= suggested to have selective control of ptype parsing by PMD at the cost of adding new AP= I. I think, we can avoid breaking exiting application by, If rte_eth_dev_set_s= upported_ptypes() is not called, PMD must return mbuf->packet_type with rte_eth_dev_get_supported_ptypes(). If rte_eth_dev_set_supported_ptypes() and successful, PMD must return mbuf->packet_type with rte_eth_dev_set_supported_ptypes() If there no objection to this API, We can send updated deprecation notice. >=20