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 4A32AA00E6 for ; Wed, 7 Aug 2019 16:20:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DBE9629CB; Wed, 7 Aug 2019 16:20:43 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A28B029AC for ; Wed, 7 Aug 2019 16:20:42 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2019 07:18:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,357,1559545200"; d="scan'208";a="198680514" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga004.fm.intel.com with ESMTP; 07 Aug 2019 07:18:43 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 7 Aug 2019 15:18:43 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by irsmsx112.ger.corp.intel.com ([169.254.1.38]) with mapi id 14.03.0439.000; Wed, 7 Aug 2019 15:18:43 +0100 From: "Ananyev, Konstantin" To: Matan Azrad , "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: AQHVTGc16KeOU/cz2kOGn4+V+To/WqbuRh+ggAAf2gCAAQTTYIAAJLwAgAAiQMA= Date: Wed, 7 Aug 2019 14:18:41 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580168A6325D@irsmsx105.ger.corp.intel.com> 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: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjZhNjE1YjEtMmQ2ZS00NGUwLWJhNWQtZGJlMDBjNWNjMTQ5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidmI0a2xBZW5mUFMyUnZkVk9uTEg5djR1bWt3Ykd2Mm5mb05MVlF0RE1sdncyOFVNYnZIMWNSNHkxOVVudE44WCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" >=20 > Hi Konstantin >=20 > 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 documente= d > > > > > for LRO. > > > > > > > > > > The ``tso_segsz`` field in mbuf indicates the size of each segmen= t > > > > > 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 suppor= t. > > > > > +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 st= ats)? > > > > 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? >=20 > Stats it is one option. >=20 > The user configured LRO, means he wants X > 1 packets to be aggregated by= the port. >=20 > Don't you think X is interesting for the user? >=20 > For example, maybe there is Y for the next calculation: >=20 > If average(X) < Y: > Stop LRO - not very good for performance to aggregate small number of pa= ckets - stop LRO. >=20 Might be, but I think user can use other metrics (let say average aggregate= d packet size) for that purpose.=20 >=20 >=20 > > If so, wouldn't it be more plausible to extend PMD itself to provide s= ome > > extra statistics? > > Just a thought. >=20 > Yes, may be interesting but it can be redundant work when the user don't = need 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. > > > > I mean HW/PMD might support LRO, but doesn't provide information about > > number of coalesced segments. > > What PMD should do in that case? >=20 > As I said, to set this field with 0 and set the PKT_RX_LRO flag in ol_fla= gs. > 0 in this case means support LRO but cannot supply the segments num. 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 not= to touch tso_segsz. >=20 > Do you familiar with PMDs that supports LRO but cannot provide the segmen= ts num? > If so, what do these PMDs can provide instead? Yes, ixgbe PMD. It does support TCP_LRO offload, and when enabled, does coalesce the packet= s, but doesn't set PKT_RX_LRO and doesn't touch tso_segsz. >=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? >=20 > No, read above. >=20 > > 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? >=20 > Will compare to 0, see above. I mean how the user will determine in advance would given PMD/HW provide th= at info in tso_segsz or not? Wait for the first LRO packet? Something else? >=20 >=20 > > Konstantin >=20 >=20 > > > > > * dpaa2: removal of ``rte_dpaa2_memsegs`` structure which has > > > > > been > > > > replaced > > > > > by a pa-va search library. This structure was earlier being us= ed for > > holding > > > > > memory segments used by dpaa2 driver for faster pa->va transla= tion. > > > > > This > > > > > -- > > > > > 1.8.3.1