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 13939A00E6 for ; Wed, 7 Aug 2019 14:35:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0CA5F2BD3; Wed, 7 Aug 2019 14:35:14 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130080.outbound.protection.outlook.com [40.107.13.80]) by dpdk.org (Postfix) with ESMTP id B41772BCE for ; Wed, 7 Aug 2019 14:35:12 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NopMFqDfnxdqYmoPJHaZeaahKGJt7wdTzLeMJ5SR7618Vt7R5YcYUZrluOr62uPUW/No94QRpd5Uu4FFC9yEigfMo4HHFEG2/g+AHRqbVAN9QMANaO+q7tJz84gPzIlY1Fz0hbwmv1oUwn2YlB9AJFz0RyoL49BTl9tSGZEOlu7JR97MeACrs/gKE35hIHcPJ1eiL4YPN5r5Ul5Kty5PqGylBjqAF/gcy07sH1ycWpn19yr/lfAQlXVw9qN+nS+AobXiT3DFm+HGN/jZprRf40AcJFsWV77DcV28ub/Hap2EWWwPxhK9a5ZyvFHMe1XgveqXwgGEnbPScCsjj4GSAA== 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=PF6PTpIo8BV5oc/z3JL3/OT2B/YgjTMMhMECRDV14p4=; b=jAKASa4ybutXffTPv+94yVwGOQgcPq6dQQhhhtHLBD4Z0+H5ons7WfsrEl3PqV05sSn7SW9i140C98WEfl0ZTw3wOG9+ay0rOESpmZtuPDgLuyd5leMBJTi6GdVKXktcIOnc4qV89SQpDerxVbIbg+TU5kR5S8GhuhAFXUQ+zkElAv4NSoAadWSvcXzSrqaTJ1b3Xl5+6Z9oMumhfRmTZ7LiUQtU++w4jDGznbO7QBQ2RnWLg2G/ic0SuM7ehbuLgHXApTm/PNuQuq8Ik1jMtAzqn8AcG+Jd6vFxabKCTE64Y+gWkaEK58AdeORpFBvDhGO3e230/NzLo1OEq2DV1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mellanox.com;dmarc=pass action=none header.from=mellanox.com;dkim=pass header.d=mellanox.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PF6PTpIo8BV5oc/z3JL3/OT2B/YgjTMMhMECRDV14p4=; b=jInoWyon78tMl9chrXAeHAgIyj1IwrQ8t6cef2yZn2XczLSR2hZpdjS4JDsNqa6ozghPoDnVAxK0VkzpRQjxcUaPpkjKajkqaLT9GD73fUf4d/uS7lQTk5dmlGYUiB4hbRMjvfFJAuNEK8kkiZjLpTYnziu+3lY/vqgyuhpHdwk= Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com (52.133.39.139) by AM0PR0502MB3859.eurprd05.prod.outlook.com (52.133.45.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.19; Wed, 7 Aug 2019 12:35:10 +0000 Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com ([fe80::ccc2:2dd4:ca86:7639]) by AM0PR0502MB4019.eurprd05.prod.outlook.com ([fe80::ccc2:2dd4:ca86:7639%3]) with mapi id 15.20.2136.010; Wed, 7 Aug 2019 12:35:10 +0000 From: Matan Azrad To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , Olivier Matz Thread-Topic: [PATCH 2/2] doc: announce new mbuf field for LRO Thread-Index: AQHVTHA1m/9TJlXicUS/FSlQ1Ewcz6buck4ggAEHdoCAAAsOgA== Date: Wed, 7 Aug 2019 12:35:10 +0000 Message-ID: References: <1565103383-23864-1-git-send-email-matan@mellanox.com> <1565103383-23864-2-git-send-email-matan@mellanox.com> <2601191342CEEE43887BDE71AB9772580168A62AC0@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580168A630E5@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580168A630E5@irsmsx105.ger.corp.intel.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c04f507-be2a-497b-852f-08d71b33b02a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR0502MB3859; x-ms-traffictypediagnostic: AM0PR0502MB3859: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(189003)(199004)(76094002)(8676002)(52536014)(64756008)(66446008)(14454004)(66476007)(66556008)(478600001)(81166006)(81156014)(305945005)(71200400001)(71190400001)(8936002)(7736002)(446003)(186003)(26005)(11346002)(86362001)(476003)(486006)(74316002)(5660300002)(66066001)(110136005)(55016002)(66946007)(76176011)(256004)(25786009)(102836004)(6436002)(2906002)(6506007)(53546011)(4326008)(53936002)(316002)(99286004)(9686003)(3846002)(6116002)(6246003)(54906003)(68736007)(7696005)(2501003)(229853002)(76116006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3859; H:AM0PR0502MB4019.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7rwhvCVCMsxzMoA+7vQVnyjQf3qtfSFoiXM8hMqKLMUQQYhXt7jGyvtbuCxIKRPSF1BtXRJRzrh4R1B71gT0UDffA/8YnA2Rgt/fVVYACsik762vPYaCn6iq5G1E8kNKNPZENkdL4waHZIjC53yK+z6mUtGYItiYpqVBurLtSCd9yiVgglEP59I4jVkSOnicL08dcqQvjiI9M8fiy62vG8ezklCG3fX22kERal5Fn8CPvd1fRh0qIHusviQnLpTAFnTryWQanvI7DTkrQ+dYrWYhYX2aYBBrRTVN4rJjxjr10l6zBjGYYRhbfCmnKtDIArFQiJ6wGfXM6tX1inqNAysNhjLnDS3fZHE6BT05CrMUtIeAOGgRO8vCAhZ2ZQMyLMZOQhiRwkdYhw/pYSRfCraKxttHLPpGx1fCG6Nz+DM= 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: 7c04f507-be2a-497b-852f-08d71b33b02a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 12:35:10.6974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: matan@mellanox.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0502MB3859 Subject: Re: [dpdk-dev] [PATCH 2/2] doc: announce new mbuf field for LRO 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" Hi Konstantin From: Ananyev, Konstantin > Sent: Wednesday, August 7, 2019 1:18 PM > To: Matan Azrad ; dev@dpdk.org > Cc: Thomas Monjalon ; Yigit, Ferruh > ; Andrew Rybchenko > ; Olivier Matz > Subject: RE: [PATCH 2/2] doc: announce new mbuf field for LRO >=20 > Hi Matan, >=20 > > > > > > > > The API breakage is because the ``tso_segsz`` field was documented > > > > for LRO. > > > > > > > > The ``tso_segsz`` field in mbuf indicates the size of each segment > > > > in the LRO packet in Rx path and should be provided by the LRO > > > > packet port. > > > > > > > > While the generic LRO packet may aggregate different segments > > > > sizes in one packet, it is impossible to expose this information > > > > for each segment by one field and it doesn't make sense to expose > > > > all the segments sizes in the mbuf. > > > > > > > > A new field may be added as union with the above field to expose > > > > the number of segments aggregated in the LRO packet. > > > > > > > > Signed-off-by: Matan Azrad > > > > --- > > > > doc/guides/rel_notes/deprecation.rst | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > b/doc/guides/rel_notes/deprecation.rst > > > > index c0cd9bc..e826b69 100644 > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > @@ -45,6 +45,10 @@ Deprecation Notices > > > > - ``eal_parse_pci_DomBDF`` replaced by ``rte_pci_addr_parse`` > > > > - ``rte_eal_compare_pci_addr`` replaced by ``rte_pci_addr_cmp`` > > > > > > > > +* mbuf: Remove ``tso_segsz`` mbuf field providing for LRO support. > > > > +Use union > > > > + block for the field memory to be shared with a new field > > > > +``lro_segs_n`` > > > > + indicates the number of segments aggregated in the LRO packet. > > > > + > > > > > > Wonder how the upper layer will use that information (except for stat= s)? > > > Could you guys provide any examples? > > > > 1. Stats, allow to calc accurate PPS. > > 2. Supply accurate information unlike the seg size which cannot be > accurate. > > 2. Let the user all the information (segs num allow an average seg > > size calculation) >=20 > So just for stats, right? Stats it is one option. The user configured LRO, means he wants X > 1 packets to be aggregated by t= he port. Don't you think X is interesting for the user? For example, maybe there is Y for the next calculation: If average(X) < Y: Stop LRO - not very good for performance to aggregate small number of pack= ets - stop LRO. =20 > If so, wouldn't it be more plausible to extend PMD itself to provide som= e > extra statistics? > Just a thought. Yes, may be interesting but it can be redundant work when the user don't ne= ed it. >=20 > > > > > Also what PMD should do if HW does supports LRO, but doesn't to > > > information? > > > > If the PMD knows all the segments size he can calculate it, no? > > 0 means PMD doesn't support it. >=20 > I mean HW/PMD might support LRO, but doesn't provide information about > number of coalesced segments. > What PMD should do in that case? As I said, to set this field with 0 and set the PKT_RX_LRO flag in ol_flags= . 0 in this case means support LRO but cannot supply the segments num. Do you familiar with PMDs that supports LRO but cannot provide the segments= num? If so, what do these PMDs can provide instead? > Still set DEV_RX_OFFLOAD_TCP_LRO as enabled RX offload, but don't set > PKT_RX_LRO flag in the RX-ed mbuf, even if it does contain coalesced > packets? No, read above. > As I understand that what happens now. > It is probably ok by me (as means no changes in ixgbe PMD)... > But wouldn't that mean no defined way for the user to determine will > HW/PMD provide that information or not? Will compare to 0, see above. > Konstantin > > > > * dpaa2: removal of ``rte_dpaa2_memsegs`` structure which has > > > > been > > > replaced > > > > by a pa-va search library. This structure was earlier being used= for > holding > > > > memory segments used by dpaa2 driver for faster pa->va translati= on. > > > > This > > > > -- > > > > 1.8.3.1