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 83588A00E6 for ; Sat, 10 Aug 2019 23:31:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4E1C92B95; Sat, 10 Aug 2019 23:31:38 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 984712B8C for ; Sat, 10 Aug 2019 23:31:36 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2259D20CF2; Sat, 10 Aug 2019 17:31:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 10 Aug 2019 17:31:36 -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=mesmtp; bh=yWYk0th5aAB4hqsKwOoFZqOoOtlFwut5C64+8cx09V4=; b=c7KP7CMWXf0M 4pshFK6UZHrfbMlPbwz564kkqcZlUfU6fBiZbBCoHn1X3L8UNpqDfdrARPp2+3J7 xPdVPaJ3T8G5p+/g180wvWyyi78oCDoe1FNFvxyzpjg5lmCC9//AKCY0fJPevIn4 lnLHLwsPEyQg3iAwoyTgbHNHVsFdtQM= 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=fm3; bh=yWYk0th5aAB4hqsKwOoFZqOoOtlFwut5C64+8cx09 V4=; b=Xa/k93283BOTopY7kiwsIuy49doOdy4r3umN8V5phZdKA53spW/Sr6xBi E5Bsxn+I8n3xqEG7vrwZgQCMVl1Jz1Bcr3XEWKlhx9YL/1B6lrMrxK2l35gqX0kH IOPZ24h1iEWjo24W5PxRvfbQDEb0xJ3SUEilhN30EBkbfSt/wVenzq/b5sNAqeHq S57c04dwFR/0g3joFWb0j+1UxAxfr42rVTsw9VRoMysv1NxzbZhh0BIw81aSr7Li ZhJjWbfS5QoMSvDCOHWSEdysDM4YEeNYMNeVPEtaQqzIjG8izi0Oe7fiwU5b75Q3 dFR1VH+TWFG+bfzR1ACuISJXuckvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduledgudeifecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 170008005A; Sat, 10 Aug 2019 17:31:34 -0400 (EDT) From: Thomas Monjalon To: Matan Azrad Cc: dev@dpdk.org, Andrew Rybchenko , Ferruh Yigit , Konstantin Ananyev , Olivier Matz , Maxime Coquelin Date: Sat, 10 Aug 2019 23:31:33 +0200 Message-ID: <4359580.12Q4qOoiY3@xps> In-Reply-To: <229e9a7b-2603-698c-d687-f7755f40bf58@solarflare.com> References: <1565103383-23864-1-git-send-email-matan@mellanox.com> <1565103383-23864-2-git-send-email-matan@mellanox.com> <229e9a7b-2603-698c-d687-f7755f40bf58@solarflare.com> 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" 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. Anyway we should avoid any API breakage in 19.11, so I suggest to do only non-breaking additions in 19.11 if possible: - fill a new unioned field for LRO segments number - not set PKT_RX_LRO (which is still related to tso_segsz)