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 C34B4A0547; Wed, 29 Sep 2021 10:03:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 45B1F40E3C; Wed, 29 Sep 2021 10:03:21 +0200 (CEST) Received: from AZHDRRW-EX01.nvidia.com (azhdrrw-ex01.nvidia.com [20.51.104.162]) by mails.dpdk.org (Postfix) with ESMTP id BBACE4068F for ; Wed, 29 Sep 2021 10:03:19 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.170) by mxs.oss.nvidia.com (10.13.234.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.15; Wed, 29 Sep 2021 01:03:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WjOLJv2ddsyssA2dGdz+/AC9TnBc0C8Y9Dgwc6dHVyqxrKMYIJU6Vet6qK8jw4lbiNn18pbGHwFikDPnevzR/DI1e9pUPsfJkut852IVP31cLzcPo6LetMEZOpJRb7sgzn1cJZxuBTtbxe+ZLiYQZqNJ5HbNybvAYPWkAW8QhRI+dcLydTYf+saO3L1uHqnkjdiG0njTa+3J6HrCSJqkzK8V9YiugXzg/sJkaCkWk9R1h63V6e0xpGcswLsJI39lKDAR6kXQIgRHVCLPp56AqyEGoZiy+jevD19iX7c01DT8joNs+wyWdA9VzfhrZ5MAoLAM7iZjJGln0FX4+UgNxA== 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=hgGQdC5t+7TlDE3U86fyVlMLtQgmUmm81VeF0VTdJIM=; b=hdd5eilwyq09Ee12fdTh/ck3w2+iEcuXyYkc8qUQIYdF3o4Uz7yFv+ERLBKt+SLVSKYb9hSV13SGiOLAFmyDG1edzJplhIWG0+a264vm34mHZTvCJFj7GFaGIwcXzu/Ta7gHvGanGxkLADtgsnInEXcusE0+RTmy82odH68m/VSY0h/GpWgH1SCx1Dv7wSgrzkOfm5srEL2XlpX6ieMubyrF+Dq9wQhX9YuoI5MnqRgZKYVSQLeIi3RiD6S4wicZpZwc7OdEACkKnreOX5SD1ulHTgDLe+bkrZ4FuW7c0DU22hntAyBwVwTF3iVvhooF3QyfxHeBpSYl5woKX34bSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hgGQdC5t+7TlDE3U86fyVlMLtQgmUmm81VeF0VTdJIM=; b=aCRuRjtWAlpevM6cQkZQt4XGEf0Pt7P7tjh40vaCQTqztnMHSMPYKbPdEkLkd6u6LJX0UjzqyVjZuWZfHDW+AKneOia/Cf9Sxi+9brCUy2bVezZolAm4QG7qu/bAylOkcRt9pd+E1q65UyWMxv1SlELiXTudaGI+EX1/9BevHV4dB7p/QmQm9qBfdlgW3TPWjPD7PDTF7ugXnJUr+7VPa18F7SScWVw8fa6KAMwC3e8zhUY9D1hsm3m5Rhqb8ZFk9gw4U8DNRekea3HnVZjmhKtMkqxeBPoWSGmN405VkWOyyPKj1swyt8A5oGHVF4oCkncXK3QspimU3LunhZubBA== Received: from DM4PR12MB5167.namprd12.prod.outlook.com (2603:10b6:5:396::10) by DM4PR12MB5344.namprd12.prod.outlook.com (2603:10b6:5:39f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Wed, 29 Sep 2021 08:03:17 +0000 Received: from DM4PR12MB5167.namprd12.prod.outlook.com ([fe80::3c73:8e07:c9ba:f6db]) by DM4PR12MB5167.namprd12.prod.outlook.com ([fe80::3c73:8e07:c9ba:f6db%3]) with mapi id 15.20.4544.022; Wed, 29 Sep 2021 08:03:17 +0000 From: Ali Alnubani To: Olivier Matz CC: "dev@dpdk.org" , David Marchand , Alexander Kozyrev , NBU-Contact-Thomas Monjalon , Ferruh Yigit , Slava Ovsiienko , "zhaoyan.chen@intel.com" , =?iso-8859-1?Q?Morten_Br=F8rup?= , Andrew Rybchenko , "Ananyev, Konstantin" , Ajit Khaparde , "jerinj@marvell.com" Thread-Topic: [dpdk-dev] [dpdk-stable] [PATCH v4] mbuf: fix reset on mbuf free Thread-Index: AQHW6bAGcPdnNJWMgUmYIFaIdvkI4aoougMAgABAexWABHC5AIABPKQAgABczACBI/kQAIAJrgkAgAAhNACAAAUngIBd4DmAgAAI6ACAAArjAIABdpQA Date: Wed, 29 Sep 2021 08:03:17 +0000 Message-ID: References: <20201104170007.8026-1-olivier.matz@6wind.com> <98CBD80474FA8B44BF855DF32C47DC35C61945@smartserver.smartshare.dk> <2065212.rItNS1eAF1@thomas> <3491197.H0bSahjnX1@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61ACA@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61ACA@smartserver.smartshare.dk> Accept-Language: en-US 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=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7261e8e7-39c8-4c5c-4382-08d9831f98b3 x-ms-traffictypediagnostic: DM4PR12MB5344: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr 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: EriClRVgG3kR9yL4KAj9WJ/fwzWavyzfIHcM+GzuNNWfjNKZBjViFaIVNdBLbxo9lqY91h5CCVn6nlPnGboObmBdMoVRMzwF0qsPuwv4fIzTXwSqkZWugVq+k/ewfNXcB2Pq9SYe/cjaawwjEzLor1yeT8k3XEOMpWaW3A3hN7pHnX/HiphwaZScHKB7W0t9OpdkmPI0luGh9n4djFgavFH0sLJlOR13fbyOXkAsMF9YVVOzYb+tS9k7Li278vBmZoFDI6g1YMqlcUrya8cOExWjA87QDa927b3msXeMWS2FyY9h7lSCzpVMGr9yLtFIZsEJ2CvyI5bcYYueN5m6ZDqV1+ZRMrqiSj8pK9mhVHmJIgDszKDVf0HKfqdOWqjjT/LcyjkZDpQpq1TkbhALzMEfMm/3J+nfV6SxLitpYNtCEXl8m/upmg7uY3X+5ra5yES150JXCeGKLs3F+GfM2NSl3Kv9k5TDpVolQ5jcWsSDs6wdIweiJgZ4A6pPZm9eF9/00KYkuQfc6Om+J6nLfJWsN3Rx0Y3Jb5KP+SMO6UOJKUPvdH4HJhInhH6qMyaf+eih6m2yZnO+0i8SvXUN37Z5GD8eHD0lCxJBG/m8kwOCFpQ8LOB2B1VltpUjugpGUTxNghmqKPchCqYvW6KrgU0xhqPcuLTb1Uu3ByqfRaAK61OFt3Viwg4zgT4iSx1R6Rux+WcQ/84PfT9VN7xSfg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR12MB5167.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(7696005)(71200400001)(186003)(6862004)(53546011)(5660300002)(6506007)(4326008)(55016002)(122000001)(38100700002)(83380400001)(66574015)(38070700005)(8676002)(66446008)(64756008)(107886003)(2906002)(76116006)(66946007)(66476007)(66556008)(33656002)(316002)(54906003)(86362001)(26005)(52536014)(508600001)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?LbN5VKxTX2EL3jDJRBl8EzH9yF4lKQtrY4sq0IQh6DUB3WcTDka82rAvOT?= =?iso-8859-1?Q?OZQS3TzacaX8fOaOVpMNZvBbOzNi+baj5/46iu3qwlH5iT06mCHtfghLAi?= =?iso-8859-1?Q?1nsjWj1noeLbK4w9cCc+0WiSZ3M+DMdYVucxWhEaMRZiTEhZWibmJOv4Hd?= =?iso-8859-1?Q?Y0wZz1rdYU07+QUNgEKrNjhRRK26wBtUcFCLJ4w3BR7ZbherAHnxLuCdN3?= =?iso-8859-1?Q?puOGHSGZ/9g+3JAD+Rc6Q7O/hpu9DdaXin+yHfhFK30f7lXH3KSKX8s6vr?= =?iso-8859-1?Q?FpAEzXkmyDpiOjSnjvqu0tTsXE+p989lPSKZW8moK24DcaC+xvj+yfC/Th?= =?iso-8859-1?Q?StkbCy+bT4t3u7FVIcSha+8AE+Gn9AX4hI95+ACsbpeRM3Hoc8zlNdWyno?= =?iso-8859-1?Q?NwiHB0coedagAFiL+Koo5mFZcF5FWQetlbi2fJMySTaGOfJuY1aeMt9gSo?= =?iso-8859-1?Q?FeqoV7T5ljXgUWrBPISgJwdL7CiZsiW1NwKmRcNmzmw+JzxfKa8TnBjOX1?= =?iso-8859-1?Q?G8efIvFukf5t0/DRc5FmgFtRtvlBggjfPym/VAcoXQheJW/EOPTVMI4SyH?= =?iso-8859-1?Q?i6nh8yg2vo2DPe8/ewA3aONkvx4G79tPB2kAgUdCRY6jHXxcKs3kEFNXqK?= =?iso-8859-1?Q?XSZHIaAQHIbK3uJW9Isk7qFu2xPnlFJZZ7jbrPpwHGWDyY3awT7EnhqAGZ?= =?iso-8859-1?Q?JyYUGwzwFJR5/A5Kph/opURO8dK0LcXNiJRsF71UWoimb0ko1IMJw0EXYQ?= =?iso-8859-1?Q?s0bRQ3L6vnKKpKHrfxjYmYfU3+A2DcNrv0hLV6+ITLtOp5WzMZVL7b0Y/b?= =?iso-8859-1?Q?jFDiH7wH7yI2p90zHY85oBx1tmgYFqpGbDaorHFLNGwFD6w2nxdvCnX8wc?= =?iso-8859-1?Q?Y2NxVlcITbDxB+ILjKJkDS9TknDsgNoYyzsWQWBy2s/LknMDUeZz2TFKT9?= =?iso-8859-1?Q?+IOard+9+R1jzrmKBQuwCxmclLnNTwFm5P7z2lyjZQoBBJmDd9TklC3GPd?= =?iso-8859-1?Q?fruqWVp6yzpfH4023E+SC36uCeSmHoe9UNPuQIaLsx/Q6H0U9wV81G8Eq8?= =?iso-8859-1?Q?yWk2xdm7DzOk36h0SQZJpSAebFw5nX3kU7q8ZixhuQ1SLltNLrCk/q4JY7?= =?iso-8859-1?Q?aFCGsTa5aiK0UIU+gMILtjg9sqYAPa8Af2ScnqeCkJHH2pwgYoNigkUNCx?= =?iso-8859-1?Q?ta2Tr5SqAn44s30X/061MplWHskafyWt+Qqeb+AMMod+mSuBErCdtNNlbX?= =?iso-8859-1?Q?47e6mpZhjBIajxZYX9X1h89I3Np0JhLi3BVdn3B9ALJmEvrp6r2oVB0xfl?= =?iso-8859-1?Q?/VuQmfV1jhvVR2OnHikiz7OKQsYaIKM9bXD0Mj0HigMuOeRvEqoD6ay04N?= =?iso-8859-1?Q?6xvcxD02GT?= 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: DM4PR12MB5167.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7261e8e7-39c8-4c5c-4382-08d9831f98b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 08:03:17.7590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Xwpqr/0taSu2IABilR65IHBEVIZ1dxC+m2CnfmdpxcI/BuL7/z8w2F+D33t0Dy7hEZGYnSgvxFsYLDBmr5TQmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5344 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" Hi Olivier, I wanted to retest the patch on latest main, but it no longer applies, coul= d you please rebase it? Thanks, Ali > -----Original Message----- > From: Morten Br=F8rup > Sent: Tuesday, September 28, 2021 12:40 PM > To: Slava Ovsiienko ; NBU-Contact-Thomas > Monjalon ; Olivier Matz ; > Ali Alnubani > Cc: 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 mbuf = free >=20 > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Slava Ovsiienko > > Sent: Tuesday, 28 September 2021 11.01 > > > > Hi, > > > > I've re-read the entire thread. > > If I understand correctly, the root problem was (in initial patch): > > > > > 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, and might affect the configurations, > > where are no multi- segment packets at al. mbuf_free() is "backbone" > > API, it is used by all cases, all scenaries are affected. > > > > As far as I know, the current approach for nb_seg field - it contains > > other value than 1 only in the first mbuf , for the following > > segments, it should not be considered at all (only the first segment > > fields are valid), and it is supposed to contain 1, as it was > > initially allocated from the pool. > > > > 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() ? > > > > With best regards, > > Slava >=20 > Great idea, Slava! >=20 > Changing the invariant for 'nb_segs', so it must be 1, except in the firs= t segment > of a segmented packet. >=20 > Thinking further about it, perhaps we can achieve even higher performance= by a > minor additional modification: Use 0 instead of 1? Or offset 'nb_segs' by= -1, so it > reflects the number of additional segments? >=20 > And perhaps combining the invariants for 'nb_segs' and 'next' could provi= de even > more performance improvements. I don't know, just sharing a thought. >=20 > Anyway, I vote for fixing the bug. One way or the other! >=20 > -Morten >=20 > > > > > -----Original Message----- > > > From: Thomas Monjalon > > > Sent: Tuesday, September 28, 2021 11:29 > > > > > > 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 > > matter 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 > > yet. > > > > > > > > > > > > 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 > > know > > > > > > 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 > > to > > > > > > conduct more investigations? > > > > > > > > > > > > > > > > With best regards, Slava > > > > > > > > > > > > > > > > From: Olivier Matz > > > > > > > > > On Mon, Jan 18, 2021 at 05:52:32PM +0000, Ali Alnubani > > wrote: > > > > > > > > > > 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 > > this > > > > > > > > > soon > > > > > > (sorry for > > > > > > > > > that). So I see at least these 2 options: > > > > > > > > > > > > > > > > > > - postpone the patch again, until I can find more time > > > > > > > > > to > > analyze > > > > > > > > > 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, > > optimization > > > 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 > > supporting > > > segmented packets at all, as a compile time option. But that is a > > different > > > discussion. > > > > > > > > > > >