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 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 ; 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 To: Olivier Matz CC: Thomas Monjalon , Andrew Rybchenko , Maxime Coquelin , "dev@dpdk.org" , Ferruh Yigit , Konstantin Ananyev 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: 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> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > > > > --- > > > > > > --- 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 > > > > > > > > > > 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