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 5AB47A00E6 for ; Thu, 8 Aug 2019 12:59:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E5C8E1BDF1; Thu, 8 Aug 2019 12:59:46 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id EDD341BDEF for ; Thu, 8 Aug 2019 12:59:44 +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 x78AxiaV026424; Thu, 8 Aug 2019 03:59:44 -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=/PwPcsrlEACd/O1dXI5ud7QKu975r7rwo/9smwZxb/w=; b=jm8+xQoj7J4KW9JwpozezX0IWRY+in8kMoilVvjSmfzzRkorXFaISDkpBx8wmQrKKdOv M2hmmtvxxnf0nKKufWjUodCVKhQw9VHd9K6OqTJdtpi55iUY49F1TFCVLoJWYIyqgGdU EUljhtrWTKP9SZYUrue2K6wWP5oykgWHwiD+bdth3irBlh48C/87hicCajlfs1x80JCv jvneqXEc2LcGbk8oExfHLmRmSh6FIeeqU60/JqGTyrFKqvCAl+nSCgbaRnd23dTVZNLx //2es29lYc7Nkc6VGy6GIyZb/qAp70NmQWeKWMeUlBRLHyU8jTlzC1W+3B6+JOsXr4dC hQ== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2u59sm38de-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Aug 2019 03:59:44 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 8 Aug 2019 03:59:42 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.50) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 8 Aug 2019 03:59:42 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E5vgsS2sOi+fNk1RJbDF/AnQ97EYl3fnhd7Fsc8XFj9F5GzK/2KXAgCr4SaitboOMv1qc7aJsb4H/YyyPEmyKq+s7ZgwyVZIYKughxsf/bzlwsO+tzMJZP2LBG/1BTbu9WY6epsrnFER+PUFQqbUvxee43A4kfV8uv6cy7PaWUyA3NpL2PseQQ64gulT/89/dVKH+sTtRoAQTWstRpmSToKoY8l5Y4n56Ver9AeZIErzASGp1NFAyB9Q7TP63omfn6Zxb5F8dHCKBib3oM8orB0i6iaNTUsH1M9lHxJVyaweUFlx3ofjsYW+IWYUow8e+J64w/9mfJaRkOFRpdrWYw== 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=/PwPcsrlEACd/O1dXI5ud7QKu975r7rwo/9smwZxb/w=; b=bkmfnmnis88A9ymUkvLyeBjp2nHJZukAfvG0wrvIqCEGrMcGs/UrbCx9RKbgvyq9P9CQtSyy7tJbSPehZnUbDWzBmsmtHEY593nMFJ2dopmHbmnPROlHwbbWuSJOEFZLl+fgEoyAIU1JZ6VoU+QgSE9OZhO6yifGOmsmYPwr7+sKD0pRcBmKC4PiOCK3f2q924+VaNOiWqyun0K6qqXXAEeCJ7+DnBNwAc3NIOqLSjZEi5qHdmnabUfGih0Ot59RqMpmgkw+GghUBM6GMiQf/IzdXV/Pvm/dufd4WcfB+YuvyT3Pfa7OphkWcZtZ4e57vbD7XjH0GLyM6T8zrYWO8g== 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=/PwPcsrlEACd/O1dXI5ud7QKu975r7rwo/9smwZxb/w=; b=vUtCX856yUQnx6zAaUOqbJ0nbjHK4cBLJ9U63U9GIFFm1HVS4wfaK92mJOl75GUKV2pctDWQ5wR2DRt3BR9WJkpxU7pu1bT8h9kWWpjiB70aicSatdSDyseK42L06SO91f+mb+GxCGw4BeTTeXjBqpDfgRccR0dqvMnmAXLSXQs= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2935.namprd18.prod.outlook.com (20.179.59.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.19; Thu, 8 Aug 2019 10:59:37 +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; Thu, 8 Aug 2019 10:59:37 +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+QCAAAHmgIAABR0AgAABAzA= Date: Thu, 8 Aug 2019 10:59:37 +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> In-Reply-To: <2601191342CEEE43887BDE71AB9772580168A63A1B@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.61.87.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 65f32225-a9be-4512-bbed-08d71bef813a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2935; x-ms-traffictypediagnostic: BYAPR18MB2935: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(396003)(366004)(136003)(376002)(346002)(13464003)(199004)(189003)(9686003)(2201001)(99286004)(55016002)(476003)(486006)(11346002)(256004)(71190400001)(71200400001)(446003)(14444005)(52536014)(186003)(25786009)(26005)(4326008)(66066001)(86362001)(478600001)(6436002)(64756008)(6506007)(110136005)(102836004)(229853002)(66446008)(76116006)(2501003)(7416002)(5660300002)(33656002)(14454004)(8936002)(76176011)(7696005)(74316002)(66476007)(81156014)(6246003)(305945005)(81166006)(66556008)(3846002)(6116002)(2906002)(7736002)(53546011)(53936002)(316002)(66946007)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2935; 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: Gjq2qFw6oQwfH6yp7pswFK+5fSZ/OgPOwZb9LDQi0fbwDq76x3jnbbDALN5gxTM+HhJGfTF0anT0h6xFVbaUuB7aHL94GqWpNDhO0HaPPXTrydoBrZMYcDMIAA+p2KnBMTcVjZSN6AWHuXSnajxFGyqA55kGANNKKByijt7O7jC/0P3I+L6e8CAsjK1m5ZVo5TkxLWI8wWlV20UZuV4otEtlJ8GbN0WoeupRloPTUSA1p2Ufu9i7QTys/Ry1dY7EMm4il14VfylQJ5wBuzSc2fHqK9aIBqa133akhuYLy44XcLXP3DfaAB7Us6fl7TGEUx94C9YIQSlyPU/Ogt64zlX1XKuGha6ceYtd35RTgCwW+QSpzfCSq0cjVrjZk8JOJvbBVKqdzRJnrV1i+INO2cUbV6QmhcnLxUxjkFJhqtQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 65f32225-a9be-4512-bbed-08d71bef813a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 10:59:37.4288 (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: lwyzIANx00A3SGZlzbKz87CCqkDWnBHHthmWpM1IIupSSi/iH1k1tUELNM2gr6NOJairhokvo9tSfg47fYnC5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2935 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-08_05:2019-08-07,2019-08-08 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 4:04 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 >=20 > External Email >=20 > ---------------------------------------------------------------------- >=20 >=20 > > -----Original Message----- > > From: Jerin Jacob Kollanukkaran [mailto:jerinj@marvell.com] > > Sent: Thursday, August 8, 2019 11:23 AM > > 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 > > Subject: RE: [dpdk-dev] [patch v3] doc: announce API change in ethdev > > offload flags > > > > > -----Original Message----- > > > From: Ananyev, Konstantin > > > Sent: Thursday, August 8, 2019 3:39 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 > > > ethdev offload flags > > > > > > External Email > > > > > > -------------------------------------------------------------------- > > > -- > > > Hi Jerin, > > > > Hi Konstantin, > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > From: Pavan Nikhilesh > > > > > > > > > > > > Add new offload flags ``DEV_RX_OFFLOAD_PTYPE``, > > > > > ``DEV_RX_OFFLOAD_RSS`` > > > > > > and ``DEV_RX_OFFLOAD_FLOW_MARK``. > > > > > > > > > > > > Signed-off-by: Pavan Nikhilesh > > > > > > Acked-by: Andrew Rybchenko > > > > > > Acked-by: Jerin Jacob > > > > > > --- > > > > > > v3 Changes: > > > > > > - DEV_RX_OFFLOAD_RSS -> DEV_RX_OFFLOAD_RSS_HASH > (anndrew). > > > > > > > > > > > > v2 Changes: > > > > > > - Reword for clarity. > > > > > > > > > > > > doc/guides/rel_notes/deprecation.rst | 13 +++++++++++++ > > > > > > 1 file changed, 13 insertions(+) > > > > > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > > > b/doc/guides/rel_notes/deprecation.rst > > > > > > index 37b8592b6..056c5709f 100644 > > > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > > > @@ -78,3 +78,16 @@ Deprecation Notices > > > > > > to set new power environment if power environment was > > > > > > already > > > > > initialized. > > > > > > In this case the function will return -1 unless the > > > > > > environment is unset > > > > > first > > > > > > (using ``rte_power_unset_env``). Other function usage > > > > > > scenarios will not > > > > > change. > > > > > > + > > > > > > +* ethdev: New offload flags ``DEV_RX_OFFLOAD_PTYPE``, > > > > > > +``DEV_RX_OFFLOAD_RSS_HASH`` > > > > > > + and ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11. > > > > > > > > > > One question about DEV_RX_OFFLOAD_PTYPE: > > > > > Does it mean that new ol_flags value (PKT_RX_PTYPE) will be > > > > > introduced to indicate that mbuf.packet_type value is set? > > > > > Or PMD will have to set mbuf.packet_type to zero, when > > > > > DEV_RX_OFFLOAD_PTYPE was not enabled by user? > > > > > > > > I was thinking when DEV_RX_OFFLOAD_PTYPE is set > > > > - mbuf.packet_type will be valid and mbuf.packet_type will have > > > > parsed > > > packet type. > > > > If not set > > > > - mbuf.packet_type can be anything application should not use > > > mbuf.packet_type field. > > > > > > But in that case, we do need a new value for ol_flags, PKT_RX_PTYPE > > > or so, right? > > > > 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? >=20 > 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_P= TYPE Flags for all the ethdev ports. Right? Rather having any complicated ol_fla= gs or port based parsing. If limit the _contract_ to following, we are good. R= ight? # when DEV_RX_OFFLOAD_PTYPE is set, mbuf.packet_type will be valid and mbuf.packet_type will have parsed packet type or the negative offload(This contract is pretty clear, I don't think any am= biguity at all) # when DEV_RX_OFFLOAD_NO_PTYPE(something similar) is set, mbuf.packet_type will be invalid.=20 > I think we need either to introduce new ol_flag value (as we usually do f= or > 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 and it complicates the=20 application to have additional check based on ol_flag. If you see any corne= r case with above section, How about just setting as ptype as 0 incase it is not parsed by driver. 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 stal= l) I did not get the complete picture of "rte_eth_dev_set_supported_ptypes(uin= t16_t port_id, uint32_t ptype_mask); instead of DEV_RX_OFFLOAD_PTYPE? scheme", Does it help? > Konstantin >=20 > > > > > > > > > > > > > > > This will avoid writes 0 to mbuf.packet_type and packet_type > > > > parsing if > > > offload is not set. > > > > > > > > > > > > > If so, what is the advantage? > > > > > Again in that case, would it be more plausible to introduce somet= hing > like: > > > > > rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t > > > > > ptype_mask); instead of DEV_RX_OFFLOAD_PTYPE? > > > > > > > > Any scheme is fine where we can skip the write 0 to > > > > mbuf.packet_type and packet_type parsing If application is NOT > interested in packet_type. > > > > > > > > > Konstantin > > > > > > > > > > > + This will allow application to enable or disable PMDs from > > > > > > + updating ``rte_mbuf`` fields ``rte_mbuf::packet_type``, > > > > > > + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respect= ively. > > > > > > + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` > > > > > > + fields on Rx and thereby improve Rx performance if > > > > > > + application > > > wishes do so. > > > > > > + In 19.11 PMDs will still update the fields even when the > > > > > > + offloads are not enabled. > > > > > > + The exact semantics of the flags will be worked out later > > > > > > + either by making them negative offloads to avoid > > > > > > + application change or positive offload to align with > > > > > > + existing offload flag > > > semantics. > > > > > > -- > > > > > > 2.17.1