From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1C780A0524;
	Mon, 27 Jul 2020 10:41:50 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 90DB61BFE8;
	Mon, 27 Jul 2020 10:41:49 +0200 (CEST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
 (mail-eopbgr00069.outbound.protection.outlook.com [40.107.0.69])
 by dpdk.org (Postfix) with ESMTP id BC9361BFE2
 for <dev@dpdk.org>; Mon, 27 Jul 2020 10:41:48 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DoJWZDpo4Qdy2APYX3JfsVuRoYrs5ZF6uJljJ5YOnd0NDHnlJqPl8x+KEbjxEfh/pbhKS6ICduwGyRb+nqNFzTRspsKltGaaN7F18zEue6+dgsJ7b3pscfx05qS2fswxE890BJDxoNdAb/tg9zT2260WkfBMxRayUnN8pr08gPVUIQguA6HW1JBGO1gYpvBhHoHgpRoV4u0usISBI/3w+LOBUItTzC9/50reMz16IMYqXdmqfyniNiVe+YNtAABeIhPOoDaVgTwTdiIuyR/uiOS+Z+Z6P6/fiBdZUms812FWurH4WfSoOcpstsZMcV5cr4a072921li7vAbjvbb9zQ==
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=g4fIbm+jjXonpnd/cYOZEq9AnslrPewu30Biyd5HRoM=;
 b=aPmrMqcapDu8aZjpbL92rir4/reHFdZaa/9b4XRl95leLOKz5p+LoftEoj0nc5H6CB3uvytIbnD03IgiNscTSAFqUvPHfi0BlCCFrrZUWGljSV7t1A0fMYzjdhrdGRcBGQFC4eoZSVn7yCptGJwcPyIEqEiPDrW0RdCn0W1ksfmL5pcMe7i+43uxIQ8WjLWf2fVKn+llVUg0qXCfo2dmVcFPePzRnMTA2CJkrPpRgK+G5eTAFYp2jfPuJpqelwWAC6H2NKMAUrf/dfH4Tj8fYT1xIK2kEEeeIx1IkPbcKqFRIOfC5skAP8tRW4A7dZYV0n6XFU/LbTlhitlITPhlmA==
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=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=g4fIbm+jjXonpnd/cYOZEq9AnslrPewu30Biyd5HRoM=;
 b=L8MPo/NgSoP9qZZUIg3zzRogTWnMs916xczMEwbXPKq1UMVdDsrddVy01Pcj5AstHG8HX4lyUi1TWQiueJLFGbES6xMdFLFSwY61yeTE14SF2RYx8sfZnY94brPrCgJYNY0JNaNKYXl76MhDrMJGzbUBAM8nnMNpdNcTiwaQBg4=
Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com (2603:10a6:208:f::11)
 by AM4PR0501MB2722.eurprd05.prod.outlook.com (2603:10a6:200:5a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Mon, 27 Jul
 2020 08:41:47 +0000
Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com
 ([fe80::c010:7069:920a:3663]) by AM0PR0502MB4019.eurprd05.prod.outlook.com
 ([fe80::c010:7069:920a:3663%6]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020
 08:41:47 +0000
From: Matan Azrad <matan@mellanox.com>
To: Olivier Matz <olivier.matz@6wind.com>
CC: Thomas Monjalon <thomas@monjalon.net>, Andrew Rybchenko
 <arybchenko@solarflare.com>, Maxime Coquelin <maxime.coquelin@redhat.com>,
 "dev@dpdk.org" <dev@dpdk.org>, Ferruh Yigit <ferruh.yigit@intel.com>,
 Konstantin Ananyev <konstantin.ananyev@intel.com>
Thread-Topic: [dpdk-dev] [PATCH 2/2] doc: announce new mbuf field for LRO
Thread-Index: AQHVTINRkilMoGiC8EGiUIfENlBOHab07O+AgcTD1oCADQnG8IBWhEmAgAAJYzA=
Date: Mon, 27 Jul 2020 08:41:47 +0000
Message-ID: <AM0PR0502MB401992E786DE9611E70E6405D2720@AM0PR0502MB4019.eurprd05.prod.outlook.com>
References: <1565103383-23864-1-git-send-email-matan@mellanox.com>
 <229e9a7b-2603-698c-d687-f7755f40bf58@solarflare.com>
 <4359580.12Q4qOoiY3@xps> <3071401.IZAg4H9azB@thomas>
 <AM0PR0502MB401939AC8E916092C37A7148D28B0@AM0PR0502MB4019.eurprd05.prod.outlook.com>
 <20200727080001.GQ5869@platinum>
In-Reply-To: <20200727080001.GQ5869@platinum>
Accept-Language: en-US, he-IL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: 6wind.com; dkim=none (message not signed)
 header.d=none;6wind.com; dmarc=none action=none header.from=mellanox.com;
x-originating-ip: [77.126.22.121]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c4573708-4469-4c1a-4da1-08d83208e618
x-ms-traffictypediagnostic: AM4PR0501MB2722:
x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr
x-microsoft-antispam-prvs: <AM4PR0501MB2722757E83424FABAAEA2C30D2720@AM4PR0501MB2722.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ONV7eIQvYZCN8+ZB1ibThHxQxEFDIGAyvVlSCSy5MqplUuUXqvpK75Ol7H9fhayTMilw5/hW2PwXM/jrVpB20/U7tZX/rZHdLC8ryn6WozS+8U8OlBveYFgeFPDY0rOWH8BWBs7XQbbNh9kHpWi49jGpk6V0nZ/khpf7O3gUB7i1AyB0bCnB1YylFt/xJIi1ta/L9tB+ol887killTDjnmQuKzGwTL6rDXYq1Xddc1tLn6ws7plFOzeLi9Xq4V0cGpOU+TghYNwTkb6Yw9GElJCKHdgHkPSrBxmMS00AnbEFYUORmMR1Id9JynwWju08Nu7CntDBVXJfrTh4WP6EPA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:AM0PR0502MB4019.eurprd05.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(86362001)(316002)(71200400001)(2906002)(478600001)(52536014)(8676002)(7696005)(33656002)(66574015)(54906003)(8936002)(6916009)(4326008)(76116006)(26005)(66556008)(64756008)(186003)(5660300002)(53546011)(83380400001)(55016002)(66476007)(66446008)(6506007)(9686003)(66946007);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: hww3DRmuoj0TRi54RyUBOVitJAI7ol6bGbd9pKTueTvNA06wgWymq+QyhTIDfHsENJG/iIXMlUM1xoHT+EHcGop1rwJGDVAQ9/vn/U81ZkxSC6o0KS4zWOgnLHJ8VaWRgFB4PiMqHp35dgXt10iYgsTbBa7LFB3a0bguF2TbZDJSAyN87MUZKBhsRTWxqQ+96Z4cHw6/e4wOJFtUm98U1WXz6ppQF+dGpnUfpSejPSZURPoNvPdLoe5QPkLLdF+42uEFiCiXcuuPjjErK2ZLyVllJk80BoeHsmQVEUXnXG7arn4ZkIWjfUt2QEN0rmOV5Cq1rrUTJeotHEq7cq1lGJU3xBVhct42KhN4REAYgm/pd+MbTCCzHEeiNR/UzXkfOMpbVj8y22mJT6plIWXJ7ppoRWdYDcJAcKK41qc2gUhu1ll/n6xjZVbvyZ/c+oNgHCUqZm2rB2rtuWKBQ08MrcDs6Jw2ViTywYBOXwQ7Cvk=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0502MB4019.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4573708-4469-4c1a-4da1-08d83208e618
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 08:41:47.3115 (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: mZRu70CVK8pQ2YIu4vg8KbtJksH9xQybEyFXliQaUsnGDFqJjFAy/b8y6P2dWCpT3DcIuI5ikutRg+l0BMG/Ow==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0501MB2722
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


Hi Olivier

From: Olivier Matz:
> Hi,
>=20
> 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 <matan@mellanox.com>
> > > > > > ---
> > > > > > --- 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 packe=
t.
> > > > >
> > > > > I think that the number of segments is more logical in the case o=
f 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 <arybchenko@solarflare.com>
> > > > >
> > > > > 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.
>=20
> Thinking about this, having the segment size for LRO is useful: it is exp=
ected
> to give the size of the segments, except the last one. The advantage of t=
his is
> to be able to resegment exactly at the same MSS on Tx (so it does not bre=
ak
> 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 segm=
ents aggregated by the HW and doesn't assume all the head segments are in t=
he 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 mo=
re accurate.

> What is described above is more GRO than LRO. But today, it is possible t=
o do
> this with the virtio driver, so removing the segment size would break thi=
s use
> case.
>=20
> Regards,
> Olivier