From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CCA5AA0032; Tue, 28 Sep 2021 11:25:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A9E84410D7; Tue, 28 Sep 2021 11:25:17 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id AEF3640E3C for ; Tue, 28 Sep 2021 11:25:15 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10120"; a="221453051" X-IronPort-AV: E=Sophos;i="5.85,329,1624345200"; d="scan'208";a="221453051" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2021 02:25:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,329,1624345200"; d="scan'208";a="538053538" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga004.fm.intel.com with ESMTP; 28 Sep 2021 02:25:14 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 28 Sep 2021 02:25:14 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 28 Sep 2021 02:25:13 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 28 Sep 2021 02:25:13 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.171) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 28 Sep 2021 02:25:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ko0kkYvCbB5v08norplU563Azx+iJIuNJuhkxUQSxa+DZRGcMZuNXmeFFkfDc8S2ngxPZgdn1bWxgfIlRqmZ+PDwYcuBj8fjkgAYz4XtjpgLrvLO/TpXiw5J0hCI4mKWSz92k56SJ+RF29pPJOlx7hmUM0RQ1y3Ju0dJ3Lnqz/iCiabwYxnXy31BUuUP/zetVaVxVmxZ6vMzyIPtZxxiaWq3SAM8nDxMZBn828xARYl1y2z1EGFy4JLUUD7wI/8YAvpz1na6OCTY1ao25I2MxyykrR6lSE9Bqm02a5Yc+zTxjmmNgJOe+Zct0AtnrFeWgkpQkvRnn1AN7SSzPUxw1A== 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; bh=oDX9/lCgp2mxr1KLmH3zgZWMwr4M6eGISUi2Y9bDjWk=; b=N/GLjjILM98XReck7vFFnx5ABIQ/XLGymJZWdSr1OOZxCKSoQsHVw2diRteoLLXjcZc071eztm7degyFJ81J+xW9XNwsShtsG4UP0XalwY24/1KTbwMQ7MtSobUKQm37g1/TSiZ5Z6JsBPubVnfywaXaO4DzB+CAsmAVVEhWgcK3NDiNVeUiYdV7iYejf2qAf2z5lCnTbDJJ9yhY1Ftj0QnJ28BzpTkfNyzt5v/uUFBmgMYRBFRQqp8rt7r2pujAWdQcdf1D+rRjkFT0pij/c3bSgLf/aDATd9xjQG0El/NJTOVREC6riS21o1UUnnIQRrHoDdX3xdpmB1jgbZoUYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oDX9/lCgp2mxr1KLmH3zgZWMwr4M6eGISUi2Y9bDjWk=; b=mouysAqafbqMrCBkYhCIt2Tp7U32W2+HngoN6N803we/d//IwvlZxTvknnEvWCa0UgbX43LpHOp20PviEHttDARzeSIe2Tkp//BBdbew52+XeD6o7EqTtow6JLcUx5bhlWJdPGYK6NCMAOzAUTEl9FCYXblaXTUmbRPn9kN+6H0= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB2843.namprd11.prod.outlook.com (2603:10b6:5:c7::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13; Tue, 28 Sep 2021 09:25:12 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::740e:126e:c785:c8fd]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::740e:126e:c785:c8fd%4]) with mapi id 15.20.4544.022; Tue, 28 Sep 2021 09:25:11 +0000 From: "Ananyev, Konstantin" To: Slava Ovsiienko , NBU-Contact-Thomas Monjalon , Olivier Matz , Ali Alnubani CC: =?iso-8859-1?Q?Morten_Br=F8rup?= , "dev@dpdk.org" , David Marchand , Alexander Kozyrev , "Yigit, Ferruh" , "Chen, Zhaoyan" , "Andrew Rybchenko" , Ajit Khaparde , "jerinj@marvell.com" Thread-Topic: [dpdk-dev] [dpdk-stable] [PATCH v4] mbuf: fix reset on mbuf free Thread-Index: AQHXgGiN866R6pG4lUidvDL8Pb4Uu6tbfk8AgAAhMwCAAAUogIBd4DmAgAAI6ACAAAR00A== Date: Tue, 28 Sep 2021 09:25:11 +0000 Message-ID: References: <20201104170007.8026-1-olivier.matz@6wind.com> <98CBD80474FA8B44BF855DF32C47DC35C61945@smartserver.smartshare.dk> <2065212.rItNS1eAF1@thomas> <3491197.H0bSahjnX1@thomas> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6af274a6-ae88-496e-9e0a-08d98261df40 x-ms-traffictypediagnostic: DM6PR11MB2843: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oj8N+LsoO3F9cnjbpmdqSvAeo+rcOUw+VYyo8MZLWvqgpPER9TTNqgsjj51/h7bUELXR4p0dGU+aYvaFfoT8qkNIbAe1YIGWq6oRM/odqZsra08YzXGEhbQyu22GsgwybbhJYtEfMwyd81Rpht8qs56gIU4zeOOv1mLsK8pStzuXpFTYBCxe9Dslc1Lu2KnyWgs0YMJEl5VETFd+jNEmfcjYW42NrMR9SvyNPnSPywk4kRZKpONkJTlEXhZ9QyHL3n0cLjifk594+X2XM02zAC6nRZ4mpTeCGxDDa0BnwqIo0OSyrP6R55x8RAVbOQYzkbp/TwniUj+todasL9L14F3wcxpQK8Wz8jW1/yPReN8C8xQvaHjTpsWV51yeVMdWwH6g/cQG+l4l4+rs9j43guHHBgvS8UArhcwqTr0bd/UDQsy6ug9BJOrUkhMKImmTlSviyWwKaztIzY9xEhRhVDZ6EybVsPjJeJb8P8zx+Gpm2HRaJtnNvPmf0ZdEY07ebCylVwKS4kxjh1L4Cz3kPECdMgX9eSdZ7dhO00yDq1N3yaI8ri1oUjVcohTO58XDQtqqjYdIVgAN99vKZ4pusVhfCyqDAmUFvsEC9VsR4Xoplomf7aCffkEIhACrcA0CBzau9q0bKtlZXi0+q2f/pQf1AtKlJa0/uq0O6FyLcTdPHtyp9S+Wh6DRssxeD3voIfPRgPi23UuB6BQANeUSUQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(26005)(55016002)(122000001)(76116006)(55236004)(86362001)(186003)(7416002)(8936002)(66574015)(33656002)(7696005)(38100700002)(53546011)(9686003)(6506007)(71200400001)(4326008)(5660300002)(66476007)(316002)(66946007)(66446008)(64756008)(66556008)(54906003)(8676002)(2906002)(52536014)(38070700005)(508600001)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?F6Aro7y31tBu1328oyhSXlH6QP5bS3oyjhQcrB3PMKk6QEsSZVaflu/8Vv?= =?iso-8859-1?Q?yRROnEsBoT8teBFddYGELtGplnsC6ooeIHlpnwlKpm5cDRc7WJ7MsBy2UH?= =?iso-8859-1?Q?wbCvWSJQS6KwqDmHvStakzh0xHCSfJxZn1EcJT++hQOUw2KenaBbtmcUB9?= =?iso-8859-1?Q?1AkaRPJQvrWZIpXEBRe4D7wytgV7ZAiAaNf9s9gtr6MTmIQdd2Fbbj/QDZ?= =?iso-8859-1?Q?mSaB3SM4Faoqxh5Yn5Fn8eTLSI0YboPNZhgnfgQ+U9p1JtZYT6w35aTGhy?= =?iso-8859-1?Q?rpj7m8RagyypBDYIwXmJJbTXbJqHOpPa7112eDMsL46/fVngpqQZDUVvBe?= =?iso-8859-1?Q?tM3m5rqaRlj3/fKwKYPGBrs9NNHgCR/kVJt4L4Vs7jQzO55Ilay6YWlDZb?= =?iso-8859-1?Q?TrXDbb0Q20Jw+2c/Ak0ogOkjir2SBSdtdi2k+/1WooE0OtPIFlM5jwJFQx?= =?iso-8859-1?Q?wcpfhoPCVw8ky0Ar8iS88ibvcthc2vfpS+Pj5Qd9Zx7nQYEV4vYNzlcNzZ?= =?iso-8859-1?Q?USUvirS8IL+4VELzg4h9LK/LYhRq9zRL8alUWQ9I7GaXPPCxgKkvWFmLQh?= =?iso-8859-1?Q?NP0qo1DYLa0kE9mcNxcS+FI4ATH0BaHISY3itfkp75IHRrM015NOOC9Ha4?= =?iso-8859-1?Q?pR8nuFOA3rosp+PeQU7UYx+qaUHSLX8pPJMv0kSdAAp51x5E9HqJTWpkfp?= =?iso-8859-1?Q?G+TXOfZp2HJZfbJocBoUVPjdcI7ZHpfY2jJRyTmmcgGB1W5QGUlSZVBvrz?= =?iso-8859-1?Q?uggtvJKPxwTKh4ghHTESvRxjFNo1ORQQpD8QKfbf3Mf7Aw0SvTYsf1dp6D?= =?iso-8859-1?Q?9Og0dzLZRymK0Qdqxq6jWdgFeGxm5n+zmMhY+PbG7cez5Czfrd6PX6RE4t?= =?iso-8859-1?Q?1+If4COE+uoUteMAKpoGLoyQH25Ay6XMlS0DrtSVJyW0LKP30GhQhvCTCN?= =?iso-8859-1?Q?LT6iYtxp3IFIyL1s67XVUMfvTtbEk8UkGATvsmT4FCbKYB60glxnIDwXoF?= =?iso-8859-1?Q?2mOqwwnZ8kD94RlxDvUFKHlJ3dYzcw+VWTgDWoY0JGv2urYjkZOjXUr374?= =?iso-8859-1?Q?1TCdTeh413SyFJiceZ7Avxwdia1d5axDrK3FHco6JTFxyzzw3kOI2DH8Sq?= =?iso-8859-1?Q?dkFUVa+a19635TaiTr75LgeK0nnH7rdzc+DXdiwmZyTZ61O7cLrrd/mIrq?= =?iso-8859-1?Q?Lv5z4yY/4SUsjRIMUnQBQy1HMJeAN747BIoF9djIKwMAhTPUw2nYlL/eub?= =?iso-8859-1?Q?qeFPA0mcCTzz60Un5s5qLC3MsYHzmm3evr7+dhH4x7cRf+zXEb5Fk0BjPd?= =?iso-8859-1?Q?7JfoBGg7+TcEu9OzTL/9hHTke0z2r5qC/hbyQBIatqFTFmrTDvNW/j5Adb?= =?iso-8859-1?Q?KP8aVWp6Zz?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6af274a6-ae88-496e-9e0a-08d98261df40 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2021 09:25:11.4500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FmLn0Z2xEVWiMr1EUINapNPsFaClFGJJsLqZ3SzSb4s440DJdj7nW37suwG1mbrZJirUamCD83dxwqwDAouas8jtAJ8rn1f4cdzyi1ZpwzU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2843 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v4] mbuf: fix reset on mbuf free X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" >=20 > Hi, >=20 > I've re-read the entire thread. > If I understand correctly, the root problem was (in initial patch): >=20 > > m1 =3D rte_pktmbuf_alloc(mp); > > rte_pktmbuf_append(m1, 500); > > m2 =3D rte_pktmbuf_alloc(mp); > > rte_pktmbuf_append(m2, 500); > > rte_pktmbuf_chain(m1, m2); > > m0 =3D rte_pktmbuf_alloc(mp); > > rte_pktmbuf_append(m0, 500); > > rte_pktmbuf_chain(m0, m1); > > > > As rte_pktmbuf_chain() does not reset nb_seg in the initial m1 segment > > (this is not required), after this code the mbuf chain have 3 > > segments: > > - m0: next=3Dm1, nb_seg=3D3 > > - m1: next=3Dm2, nb_seg=3D2 > > - m2: next=3DNULL, nb_seg=3D1 > > > The proposed fix was to ALWAYS set next and nb_seg fields on mbuf_free(), > regardless next field content. That would perform unconditional write > to mbuf,=20 I don't think it is a correct understanding see below. Current code: if (m->next !=3D NULL) { m->next =3D NULL; m->nb_segs =3D 1; } Proposed code: if (m->next !=3D NULL) m->next =3D NULL; if (m->nb_segs !=3D 1) m->nb_segs =3D 1; So what this patch adds: one more load and compare. Note that load is from the first mbuf cache line, which already has to be in the L1 cache by that time. As I remember the reported slowdown is really tiny. My vote would be to go ahead with this patch. > and might affect the configurations, where are no multi-segment > packets at al. mbuf_free() is "backbone" API, it is used by all cases, al= l > scenaries are affected. >=20 > As far as I know, the current approach for nb_seg field - it contains oth= er > value than 1 only in the first mbuf , for the following segments, it sho= uld > not be considered at all (only the first segment fields are valid), and i= t is > supposed to contain 1, as it was initially allocated from the pool. >=20 > In the example above the problem was introduced by > rte_pktmbuf_chain(). Could we consider fixing the rte_pktmbuf_chain() > (used in potentially fewer common sceneries) instead of touching > the extremely common rte_mbuf_free() ? >=20 > With best regards, > Slava >=20 > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Tuesday, September 28, 2021 11:29 > > To: Olivier Matz ; Ali Alnubani > > ; Slava Ovsiienko > > Cc: Morten Br=F8rup ; dev@dpdk.org; David > > Marchand ; Alexander Kozyrev > > ; Ferruh Yigit ; > > zhaoyan.chen@intel.com; Andrew Rybchenko > > ; Ananyev, Konstantin > > ; Ajit Khaparde > > ; jerinj@marvell.com > > Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v4] mbuf: fix reset on mbu= f > > free > > > > Follow-up again: > > We have added a note in 21.08, we should fix it in 21.11. > > If there are no counter proposal, I suggest applying this patch, no mat= ter the > > performance regression. > > > > > > 30/07/2021 16:54, Thomas Monjalon: > > > 30/07/2021 16:35, Morten Br=F8rup: > > > > > From: Olivier Matz [mailto:olivier.matz@6wind.com] > > > > > Sent: Friday, 30 July 2021 14.37 > > > > > > > > > > Hi Thomas, > > > > > > > > > > On Sat, Jul 24, 2021 at 10:47:34AM +0200, Thomas Monjalon wrote: > > > > > > What's the follow-up for this patch? > > > > > > > > > > Unfortunatly, I still don't have the time to work on this topic y= et. > > > > > > > > > > In my initial tests, in our lab, I didn't notice any performance > > > > > regression, but Ali has seen an impact (0.5M PPS, but I don't kno= w > > > > > how much in percent). > > > > > > > > > > > > > > > > 19/01/2021 15:04, Slava Ovsiienko: > > > > > > > Hi, All > > > > > > > > > > > > > > Could we postpose this patch at least to rc2? We would like t= o > > > > > conduct more investigations? > > > > > > > > > > > > > > With best regards, Slava > > > > > > > > > > > > > > From: Olivier Matz > > > > > > > > On Mon, Jan 18, 2021 at 05:52:32PM +0000, Ali Alnubani wrot= e: > > > > > > > > > Hi, > > > > > > > > > (Sorry had to resend this to some recipients due to mail > > > > > > > > > server > > > > > problems). > > > > > > > > > > > > > > > > > > Just confirming that I can still reproduce the regression > > > > > > > > > with > > > > > single core and > > > > > > > > 64B frames on other servers. > > > > > > > > > > > > > > > > Many thanks for the feedback. Can you please detail what is > > > > > > > > the > > > > > amount of > > > > > > > > performance loss in percent, and confirm the test case? (I > > > > > suppose it is > > > > > > > > testpmd io forward). > > > > > > > > > > > > > > > > Unfortunatly, I won't be able to spend a lot of time on thi= s > > > > > > > > soon > > > > > (sorry for > > > > > > > > that). So I see at least these 2 options: > > > > > > > > > > > > > > > > - postpone the patch again, until I can find more time to a= nalyze > > > > > > > > and optimize > > > > > > > > - apply the patch if the performance loss is acceptable > > > > > > > > compared > > > > > to > > > > > > > > the added value of fixing a bug > > > > > > > > > > > > > > [...] > > > > > > > > > > Statu quo... > > > > > > > > > > Olivier > > > > > > > > > > > > > The decision should be simple: > > > > > > > > Does the DPDK project support segmented packets? > > > > If yes, then apply the patch to fix the bug! > > > > > > > > If anyone seriously cares about the regression it introduces, optim= ization > > patches are welcome later. We shouldn't wait for it. > > > > > > You're right, but the regression is flagged to a 4-years old patch, > > > that's why I don't consider it as urgent. > > > > > > > If the patch is not applied, the documentation must be updated to > > mention that we are releasing DPDK with a known bug: that segmented > > packets are handled incorrectly in the scenario described in this patch= . > > > > > > Yes, would be good to document the known issue, no matter how old it > > > is. > > > > > > > Generally, there could be some performance to gain by not supportin= g > > segmented packets at all, as a compile time option. But that is a diffe= rent > > discussion. > > > > > >