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 39BF5A00E6 for ; Thu, 8 Aug 2019 12:16:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 056D91B9CD; Thu, 8 Aug 2019 12:16:59 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40072.outbound.protection.outlook.com [40.107.4.72]) by dpdk.org (Postfix) with ESMTP id 9AE651B9AD for ; Thu, 8 Aug 2019 12:16:57 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IDAuhFOETsXE4CS/Yh6LzZCvIyEW2p0Pay9xJ80YvP0i6UG0F/v8jKJKJA9TjziCiafv2wq/YCN9ZSRyJLsaMIQHtrB+BAL44jlc/7SJUd89+G8RUS0ez+x3eN5qgGT81whIIVkP0yZKE19ZjNY+qJAaAWm09EonJqn5g4Ud6k9cXpbCwEEBUvh7PfRhXWsSQOSj4gm0RVpFgNT24/zlNFEcWZqFnigjV25XW6/o8483gGvZ0OmfcvNKmlso1yEmmZPfT71Dggq3Xue9muNAkrN5q1YddAsO1wRKHjm52AD/RDojt46pvyUTqK8YuJOtR2qeWBXGuNDD1fgFryMWYQ== 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=Qw6B90+Tv8krLB+OQkZWggMiEVpFu56vYxwlzrps/2M=; b=Qliy8iUzc3gkByBK0jUMdIxjR5nZQeeMR4EQ8t9w9kvZiyJKyDSVWZD99ROqrYD4RN9V1LUWm0g5YRe671wRioX9XufQNa7NH1YGxJW5jb1aT6NydsNiW0fkMXAtowlisrFtUkQm/d3ow4TrOxWb1krBJWBtqPY65WZzTp8AYs2mMyZhkoICeKtb98m5McWwQPNCm8CrgjKzK/u63w89siABvNQb+J1+ogvuId4kDgdSGxSoQXSFJAkO0O8SRuGyn759rxqrttGK6K+RSeVqpQAbUSvqfVH4yMyX7GIkf6tst48oB55F3o2Y2eyqBAFTQhjF2kHrPCIBXtndwjOcFQ== 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=Qw6B90+Tv8krLB+OQkZWggMiEVpFu56vYxwlzrps/2M=; b=UXEqD1YuNRoy3FpWKX7mU2zCMb5gmQS2SDWHSrkX9kFFoXroLI5XVwNqbt1PApk3EzfVhCWZFpj4Nf3Y73p3UKQVXiEqBGJDAEluloxr5XYaXQfUljd7guLBJhhNNso0GYMgaPzXC8fcjnu0VtOnkN5GKH/78svTQDBytY5qpeE= Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com (52.133.39.139) by AM0PR0502MB3922.eurprd05.prod.outlook.com (52.133.45.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Thu, 8 Aug 2019 10:16:56 +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.2157.015; Thu, 8 Aug 2019 10:16:56 +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/FSlQ1Ewcz6buck4ggAEHdoCAAAsOgIAAOFOAgAFLr5A= Date: Thu, 8 Aug 2019 10:16:56 +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> <2601191342CEEE43887BDE71AB9772580168A6325D@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580168A6325D@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: [85.64.81.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 199bf053-d193-4fe3-79ef-08d71be98ac9 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:AM0PR0502MB3922; x-ms-traffictypediagnostic: AM0PR0502MB3922: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(366004)(346002)(396003)(76094002)(189003)(199004)(7736002)(5660300002)(86362001)(71190400001)(52536014)(71200400001)(186003)(25786009)(7696005)(446003)(6116002)(3846002)(2501003)(11346002)(476003)(26005)(14454004)(478600001)(102836004)(486006)(256004)(74316002)(4326008)(6506007)(53546011)(8676002)(6436002)(66066001)(9686003)(110136005)(316002)(99286004)(76116006)(76176011)(53936002)(8936002)(81166006)(2906002)(81156014)(66946007)(66556008)(66476007)(33656002)(64756008)(66446008)(55016002)(229853002)(305945005)(54906003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3922; 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: Vs3oj5MnLIMKOPvKUyWIleFbRcc3HnkZzfLNCF3CHk4UrTwqDNUjRYuRXrNwimTrkjO6TwWMjAKIz3gpkf3K/NxMWZpqdMvPevNWFJft7kqo7lawfaugQwWvSA+LyCgcPOeF6sU3GYX8QjeVUGyZe39pOJFV/4PhhWwLoy8bX33GKODyQNwsSp4OBXXZ3i/jZ8gyA7mGuIjzmH7aC589tOlInPrkzxXixflkmNgBQ71rsqtrXyxiiGVyCf8WJ6ZE1mnPA+4BuXNDHW9qpiz4esr5Pjo1XA4Ic1BTnOPohYLiCwJWMXla6iWK/dXpkiVHrNKaPRgyFgh7ZqhLFHLZ7snFzRL5cgybVztTT2JEWwR7LOC0V6puJoLCgjxmO51YeoSgyooAwKU2yXEpEL1Rli3K2WdSte43nKZK05hhZV4= 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: 199bf053-d193-4fe3-79ef-08d71be98ac9 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 10:16:56.4485 (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: izp4MxPQ1SWCJggMgYDV1U386MOZ9IfJFevKlwfBUvdbcMfXh1+Ol2CAm1SiYYuKeFh+YcVSzMxtvEvAQL4Bcw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0502MB3922 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" From: Ananyev, Konstantin > > 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 > > > > > > Hi Matan, > > > > > > > > > > > > > > > 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 packe= t. > > > > > > + > > > > > > > > > > Wonder how the upper layer will use that information (except for > stats)? > > > > > 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) > > > > > > So just for stats, right? > > > > Stats it is one option. > > > > The user configured LRO, means he wants X > 1 packets to be aggregated > by the 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 packets - stop LRO. > > >=20 > Might be, but I think user can use other metrics (let say average aggrega= ted > packet size) for that purpose. Yes, but I think it is better to supply the segs number which is an accurat= e number instead of average size of segment. Then, user can decide any calculation he prefers. >=20 > > > > > > > If so, wouldn't it be more plausible to extend PMD itself to > > > provide some extra statistics? > > > Just a thought. > > > > Yes, may be interesting but it can be redundant work when the user don'= t > need it. > > > > > > > > > > > > > > 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. > > > > > > 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_f= lags. > > 0 in this case means support LRO but cannot supply the segments num. >=20 > Ok..., but then what for then to set PKT_RX_LRO at all? > From PMD perspective it would be easier not to set that flag at all and n= ot to > touch tso_segsz. The user should know that LRO is working. LRO flag should be set in any cas= e. > > > > Do you familiar with PMDs that supports LRO but cannot provide the > segments num? > > If so, what do these PMDs can provide instead? >=20 > Yes, ixgbe PMD. > It does support TCP_LRO offload, and when enabled, does coalesce the > packets, but doesn't set PKT_RX_LRO and doesn't touch tso_segsz. I think it should be changed to set the flag. >=20 > > > > > 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. >=20 > I mean how the user will determine in advance would given PMD/HW > provide that info in tso_segsz or not? > Wait for the first LRO packet? Something else? Or wait to for the first LRO packet, or we can add a new ethdev capability = for it. What do you think? >=20 > > > > > > > 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 > translation. > > > > > > This > > > > > > -- > > > > > > 1.8.3.1