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 66B33A0524; Mon, 27 Jul 2020 11:07:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 35A341BFF5; Mon, 27 Jul 2020 11:07:23 +0200 (CEST) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 887CB1BFE8 for ; Mon, 27 Jul 2020 11:07:21 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id f18so14078715wrs.0 for ; Mon, 27 Jul 2020 02:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qJZOEVFahEd2uDVI6NxMYTI0ZwiPpIJzBN7z3hfe6y4=; b=RwziADx8jUsx+IBcVdxi3OVBjZdqR93A9L678Q4qAB+1YWilR8CcV6NXDVLrNo2sYe uRktdHOqIMD90h1+qKzfO/AT3HXNvTsTnPTL7wSJzavW9ea9O8iSazXfbKX3ofYbMx/+ R/JfcKxikn9HD5Tk+6iVxjE2wiPs6hvU8n7+QwFc2b/kNkNIAGndQXG+0avoLWR7kuwN pEx9tOOSZf18icoNYP7uvibU0ITx82d/KF5v+zmeoU1LamKMsbwEz78iO8bsc4EBKdyu QllI06soJViU5tfLBiWCmTOx6k2i/kcL3cyKk6I6FU4zeZqibqohfsndTxBCEKckM0oM RjgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qJZOEVFahEd2uDVI6NxMYTI0ZwiPpIJzBN7z3hfe6y4=; b=RdEZXsrPGu5USqn8Xe4aexjxfJ0XUSjwF2zl6+q0y4JYmNjHgg/6kYLLnwjOfeU45y MEFmGNCxHdGQnNsVuAZ1ouJoEfagGfX9p+HyCdPlhwJPqpuE8jVgC2wVT34Y/hSRmzYL B6zhHFlnZiLs7o/A3twv5taglICb1ivRAvVcY/6LLCxIk9Up1DReyn8AYrMQSVy9mXeO w9tYogx93x8X06FICg/Dn9OUZ7dtLKPHIxsi5TxEkcL4klDdR/v+aXr8579O8McldpI2 hDGi9rsZu1n4MaqAo6HqsqtxWZ2oY8Psvc5PlHV7vyNZITY2Hk5V04m7PnVbaumMklW4 fUhg== X-Gm-Message-State: AOAM5331mocZGU/EDcWghqD7r/MQ6vhAfo/aYVVgLZZQwqbPq3f4uZjx 7pefy6hKcBOys25NBbE3luc89g== X-Google-Smtp-Source: ABdhPJxyQJfGq88p6vQm7TP3LqKAI0KVd0wnZBis44r4I00DLdwV0XYHUE/zLENVP5aFM8BET2d7yw== X-Received: by 2002:adf:f48d:: with SMTP id l13mr18761392wro.43.1595840841096; Mon, 27 Jul 2020 02:07:21 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id q4sm15280541wmq.33.2020.07.27.02.07.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2020 02:07:20 -0700 (PDT) Date: Mon, 27 Jul 2020 11:07:19 +0200 From: Olivier Matz To: Matan Azrad Cc: Thomas Monjalon , Andrew Rybchenko , Maxime Coquelin , "dev@dpdk.org" , Ferruh Yigit , Konstantin Ananyev Message-ID: <20200727090719.GS5869@platinum> References: <1565103383-23864-1-git-send-email-matan@mellanox.com> <229e9a7b-2603-698c-d687-f7755f40bf58@solarflare.com> <4359580.12Q4qOoiY3@xps> <3071401.IZAg4H9azB@thomas> <20200727080001.GQ5869@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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" On Mon, Jul 27, 2020 at 08:41:47AM +0000, Matan Azrad wrote: > > Hi Olivier > > From: Olivier Matz: > > Hi, > > > > On Tue, Jun 02, 2020 at 06:49:01AM +0000, Matan Azrad wrote: > > > Hi > > > > > > From: Thomas Monjalon > > > > 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? > > > > > > > +1 to make the change. > > > > Thinking about this, having the segment size for LRO is useful: it is expected > > to give the size of the segments, except the last one. The advantage of this is > > to be able to resegment exactly at the same MSS on Tx (so it does not break > > PMTU). This is needed if you want to do a bridge or a router with LRO > > enabled. > > Yes, you right it may be useful. > > I don't familiar with other vendors, but mlx5 HWs supply the number of segments aggregated by the HW and doesn't assume all the head segments are in the same size. > > So, we just put in the current field packet_size/num of segments. > > So, maybe we need the 2 options as uinion or as 2 separated fields to be more accurate. Yes. Having ethdev capas would help to know what the PMD can do (basically, reassembly of same segment sizes or not). Renaming PKT_RX_LRO to PKT_RX_LRO_SEGSIZE could make sense, and the new one PKT_RX_LRO_PKTNUM could be added in case the packet number is provided. I have no strong opinion about union vs 2 separate fields. If a new field is added, I think we should prefer a dynamic mbuf field. > > > What is described above is more GRO than LRO. But today, it is possible to do > > this with the virtio driver, so removing the segment size would break this use > > case. > > > > Regards, > > Olivier