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 288CAA04A4; Mon, 25 May 2020 01:41:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 149DA1D5D9; Mon, 25 May 2020 01:41:57 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 19BC71D5C4 for ; Mon, 25 May 2020 01:41:55 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5D7835C008B; Sun, 24 May 2020 19:41:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 24 May 2020 19:41:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= 2G391+4OkoW8VThtLMW+lEeJzqAB6IFjr2dCl5W2W4k=; b=sQXfGfHsHkiXLtIZ XpqBK5FHKtjqwqwM589bFw5GS3FEyXajhmDY5/Yrgf6vrM/syxHPtQaoL6X1xGQt 2+0/GbJv7He720RoldryfiLAc1ztpeivOnJaIqwXB19LLVPqzFmsoBaVyFaki6IX 985Zsm9xhiVLTJtQoTst+n7kJ4RKEnNYGwzEtSleVtfhQVvWDL9hueOZOfg/lYqz 4jTejtQmSNcr2YPJIt1t8oozFYGyLopnP17NBfPBDKRluKS53dO/ezsCe+N28QRo kIPRM9qZyCwV2IGbyEPdt2NJ+5YBC+xlmTgnbQFzTMg2+XYOPjhr7TmiQ8sJu3F3 xBnV5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=2G391+4OkoW8VThtLMW+lEeJzqAB6IFjr2dCl5W2W 4k=; b=lWS+oJT2KBbDsNLVm0IvSqBF229mzOoONf4eZjMXhxQmFXQq6NpqFQbsD wSduuu0DtpIW9GHovsxuBhJBOrmW6K0m1n7pLCiRjE6twIiqMS1A46HR45EoSla7 +6ypXv/WRqXks2/BTU1q2QqBwzHKgvULxR3y/onC9IURhpS4AFkOIN/J3uTZcBa2 3l4zLZ58cX0trU2ExcmP5JjEKfWnH06KBreoq50/UB0U+6K9Fp3L3eU6IrowRzlB 1WvLlwbKRagzNUs/pFcrmPf9rYZiMgTnq8xkG9iL0J6ILOvnzM7mMZ0G3YUtWPdp FfZCEujaFdAfEuFr6Hu9hxkx9SnEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduledgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D8D3306653F; Sun, 24 May 2020 19:41:52 -0400 (EDT) From: Thomas Monjalon To: Matan Azrad , Andrew Rybchenko , Olivier Matz , Maxime Coquelin Cc: dev@dpdk.org, Ferruh Yigit , Konstantin Ananyev Date: Mon, 25 May 2020 01:41:51 +0200 Message-ID: <3071401.IZAg4H9azB@thomas> In-Reply-To: <4359580.12Q4qOoiY3@xps> References: <1565103383-23864-1-git-send-email-matan@mellanox.com> <229e9a7b-2603-698c-d687-f7755f40bf58@solarflare.com> <4359580.12Q4qOoiY3@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 10/08/2019 23:31, Thomas Monjalon: > 06/08/2019 20:17, Andrew Rybchenko: > > On 8/6/19 5:56 PM, Matan Azrad wrote: > > > 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 > > > --- > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > +* 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. > > > > I think that the number of segments is more logical in the case of LRO. > > The question (already asked by Konstantin) is why it is needed at all > > (statistics?). If so, it still makes sense. > > > > Segment size is misleading here, since not all segments > > could be the same size. So, > > > > Acked-by: Andrew Rybchenko > > > > As far as I can see bnxt and qede do not fill it in. > > mlx5 and vmxnet3 have the number of segments (vmxnet3 has segment > > size sometimes and sometimes use a function to guess the value). > > So both will win from the change. > > It looks like virtio does not have number of segments. CC Maxime to > > comment. > > I support improving the API for LRO. > Unfortunately, the consensus is not strong enough at the moment. We had no progress about LRO field in mbuf. Is it a change we would like to have in 20.11?