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 38F3AA0032; Tue, 28 Sep 2021 11:00:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C595940E3C; Tue, 28 Sep 2021 11:00:42 +0200 (CEST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2058.outbound.protection.outlook.com [40.107.96.58]) by mails.dpdk.org (Postfix) with ESMTP id A861440DF6 for ; Tue, 28 Sep 2021 11:00:40 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RvrEsbJkRJpzB7nHzCt1a7qpCC4IRYrRvbeVqjK5v1RIJOXa7jhVWCAe/EWUjWCCRvpzihS4jeAuVEkF9y6oIm/Nj9gWVe0LboXFt369UzdYEXsZPb6Ml/pl5x1Xwxdg8EVnridqP2Nl6P37Y2j0U4xHrPdXj60hWsch8n6MWQMFYpdUdrN0byKA//a8WqvVy7eCNUzQUTRjclwrjfxnNpTnhJ5qLRCaJKCJ1y2iT6+9J5QBZte5tj6M2J+pc1f6GoUXdsPb4F28ZIggMLcewD/+HY160N+WkbMv54zsuILZgTz8lesqGuWQFSghuW4GSodQ1BeMYGXuF7jyxz4eWA== 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=RD9gq5Ea5itrhDh2Zg+xAGzvZhO8y5GA10omARrRi7g=; b=B1oj5/ecms7urm/VreDXZwyn9AfSxWo2bWp3Oe9Y6c0GDC85+tcr6y98k9JjmbrPRf8gKu8aav2G6A2fhPMlv74YYhPO8fTnkcW3dApX8f6FPmo+L65lmM2RnKUfSYTMMom9CEWypfsnH43Ej3yT18jMQr/aQSSId8t1KLELUwXbaaoaY/pKknFV+RESIreHvibNJJWby0N6gcRF1/Cgwy5kIw5KmPMu7JTlibTimxG513VuzqdqbS6MQIf53a3hMhSAbL9s018kMgizxI7vB32jnrCu/D6CO1BKzTioUYltrT8cee/ZY9LLLxjwhHVoRvOWFfGbcIzR4XNcTe+u/g== 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=RD9gq5Ea5itrhDh2Zg+xAGzvZhO8y5GA10omARrRi7g=; b=PaBHp7XKgrSps8h/OG8KjUcEcPE87ijSY8l0mx3SrHymWoNQzVx5JPQb57XO9Qi+V3uShaPDOEtdhWwFp18sWLBC66ng6mG6K75iXDNAN/TOGL4gWL26Kccw8Rgdn2t71xWn2BxfUBs2p6XPEB4VJ6gq2m2uP1ZOrmOOe1FZt83cbono939Jt4LvfC6aArTIR2vfycEXTLQvTLGxA6UiKmTOIQUUBHpewk0q/yNkKciR5KnvLpkwRaNxlAj8Ya+WNYC8nwcTiiYhxCwp4eHUMPas1u2hedaYJgi11HQi7Gf9DUroE7dCdh6vw3Lv7zvq28O/zgUFe8n3eq3DDKlG3A== Received: from DM6PR12MB3753.namprd12.prod.outlook.com (2603:10b6:5:1c7::18) by DM5PR12MB2422.namprd12.prod.outlook.com (2603:10b6:4:b9::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.15; Tue, 28 Sep 2021 09:00:38 +0000 Received: from DM6PR12MB3753.namprd12.prod.outlook.com ([fe80::e550:35a2:96e5:657f]) by DM6PR12MB3753.namprd12.prod.outlook.com ([fe80::e550:35a2:96e5:657f%4]) with mapi id 15.20.4544.021; Tue, 28 Sep 2021 09:00:38 +0000 From: Slava Ovsiienko To: NBU-Contact-Thomas Monjalon , Olivier Matz , Ali Alnubani CC: =?iso-8859-1?Q?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" Thread-Topic: [dpdk-dev] [dpdk-stable] [PATCH v4] mbuf: fix reset on mbuf free Thread-Index: AQHW623VmsTXVlWnIEigt6XNenzAZ6otrogAgAD11wCAAFyesIEj+T4AgAmuCQCAACE0AIAABSiAgF3gOICAAAVDwA== Date: Tue, 28 Sep 2021 09:00:38 +0000 Message-ID: References: <20201104170007.8026-1-olivier.matz@6wind.com> <98CBD80474FA8B44BF855DF32C47DC35C61945@smartserver.smartshare.dk> <2065212.rItNS1eAF1@thomas> <3491197.H0bSahjnX1@thomas> In-Reply-To: <3491197.H0bSahjnX1@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32b2868d-51cf-4d6b-8782-08d9825e7124 x-ms-traffictypediagnostic: DM5PR12MB2422: 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: 1WloEnvbHOv++oKFDktnXN2GHoT5egCCfYjtMozKCpN6luck/ijcCC0j+s/fiC2KbdzWHo3lO6bgZjRAAMzK4HpzvG4H2T9cLclvZl7jTxToKEdZpgEFHgwRMii3JnkzIcPJlBvoD3sTsdQb6nTHtuCkTmsqvcX0DGlaH44korLsPS4woVFH5hOl7RprXyirvjlou08Kb/36iwctn0J5YnAZUJkn6b7PV2rTuGzKB0BzkQmugo0W9IFSe+jYMRDQMEZhRNTXm/+L3RJNUQQZkbRg2HmT8XUk19k2DYGRSiLCnpTMYN47Bt/ISuIpuVGrrZlWIpmpeCtH448g+Id1XPzPc3ijyWdZpuah0NOl+YtaKmsEasmg/zCSfQFDf5pyMXFnOeKT4/pvWBvejxUUD7+JGtWEtkfO3OYT55yIoxsMsKJScRn/PeSl5r3O1eHWJvyoYdi86A4h9APxKr6eY7mpRH9FuuGwUDc1uQA14r0IrYzdnu5QS8j8sUNe0pKnJR/paOcSzzsvpITqgpm1koxVasXr8kgtdu7Vz894HO7vxajSjEMHYkDFCoszJHv3qgy8IT4VYgH3V+02kgrrp3Z1NRtjXllHBZVmKujKusPzRukUyJXJzNav1cILo454iUMvR3oCC0obuQ18cgBKuNu0WdxauNwTdDvldEPYXrnr5oXl2gnnGSjKnwsupS2sUK0W3zs0XuubsWCdGFp2UQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB3753.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(110136005)(26005)(7416002)(53546011)(6636002)(5660300002)(4326008)(86362001)(6506007)(54906003)(7696005)(33656002)(186003)(2906002)(316002)(38070700005)(9686003)(8676002)(55016002)(66574015)(71200400001)(8936002)(122000001)(52536014)(66476007)(66946007)(64756008)(66556008)(76116006)(66446008)(38100700002)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?LW/qMCakSwKZujnYSg52c8GEI278HizFKb5qjvt2HnVP4Ne4V4S8O75Qg/?= =?iso-8859-1?Q?XprblcRSs874n7KWgzdXH4DB1csodH6VV8HhfuAe36le4Ach0KXyzuL3mK?= =?iso-8859-1?Q?Qm6ssrQ62i3806veRwWB6202SH/rN77QkFWfWA0/h79PtX7NVtZ9yZQQOD?= =?iso-8859-1?Q?jVNgPN6KJ6jyDLDN/xxw0j8bhBaQG7ChjnGyBhGGIBIX+Te3egIF9YuDrW?= =?iso-8859-1?Q?oxr0YbqIL5XiduP0MVWO6CJIhWB9Rhj+CcapZ6KcpL4W35lt8IgQHmaknD?= =?iso-8859-1?Q?LIDEdncjHflYOr29HLp4Yk8nncDdZ7Lh71CSc1FQzEDnKPETeObZMLeOhx?= =?iso-8859-1?Q?No4qeS9QpKdmXHdLZMLhhrpM8lT+rTuEjfxQs+nn/q32tDeAFw9t9HK5Io?= =?iso-8859-1?Q?r5bhu0hAbkPKhs+WBQjgHZfjRVYfxbL/6HehCUSKYNIz/0C6XzsHkVZ0S0?= =?iso-8859-1?Q?2iuCcJCs/Nbosi3a0A1VpU9EW+hlC91sdfpMIIs5XEiTfYv+4xKtIL169A?= =?iso-8859-1?Q?9OnzTnv+WaljeJ4V3/t+XHxtjef0LbXP0kh/qydQojGp8X2wfsQdUjoanT?= =?iso-8859-1?Q?uPOl7Iw/j4myMNDB+6sIuZdQs2+W++TljhZIpUyTnpbj6AQeKIowRhFZpw?= =?iso-8859-1?Q?PcEgoKRdMiqQy8mfLKNyUbCd2PFQ6hp4InZuBorwkh95OGQ9ggOlRXTjeN?= =?iso-8859-1?Q?aaktus1uD+m39r/iB/93elxNQxjCNV5bU3Zg9vuqpKkyWMW25agCPdi2l5?= =?iso-8859-1?Q?gTpZ9DUia1J/zE8G+7ax+NsmCgSBcGqGBBVdf3aVg8RFrTIziXdE+2PK47?= =?iso-8859-1?Q?4wplB9NpE4l/cMEa8XbD3HQmbwjC3vBMH/g91JzPNZflHqbvT4EBrjTNji?= =?iso-8859-1?Q?XDWYSzHNJD5Gwdgce3y/N2k+aZWKuiO7YN+o36Hf3Kvshs8O4kH99t1Rtr?= =?iso-8859-1?Q?ZR3lf3mwbP3QEy24Zz/1t2OK2Wql0vEHt35IdOzjTv2AlPHsQZrfr2fSDL?= =?iso-8859-1?Q?lY7fYiOwOWxp+m7koMmsUmRuvvPgwD6j3iF/midZDwi5i8k1GWGlZtPfTA?= =?iso-8859-1?Q?im+YiQAmJEfMzkEpTe6Wg4AHDE+393hOsbFmC5mNUW6VipbVQC6bY+PBdb?= =?iso-8859-1?Q?KskQCbkk1nOgT6juV4fUhqT4hsduG0U/HQ0b9a5YkSDxOXEB+Yt75sGSVy?= =?iso-8859-1?Q?rLTzoOb3xuXcQKPa2sOVJScSfVmRlXzo96WX+nJ2uXbyk6yW8vo5pC7Tjr?= =?iso-8859-1?Q?mPVqz5/77WeAt4LAxEvqPa+Hmh/7/m2gzSDZjNQeEiu5ge/C2czfqfau/I?= =?iso-8859-1?Q?K3/lOMrkn6/ybS3v3psn7F8tI5253k7Cxt9Ywvp206vboSY=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3753.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32b2868d-51cf-4d6b-8782-08d9825e7124 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2021 09:00:38.5472 (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: +fBbhGHolVQIxTxtSVHmEDbDO/C9SyZf9ZXSEYRlLZK5VCJ5yPJD/FH93G8OpYJokWozdiwYkJxA6nyLbFVA/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB2422 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,=20 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=20 > (this is not required), after this code the mbuf chain have 3=20 > 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 shoul= d 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 > -----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 mbuf > free >=20 > 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 matte= r the > performance regression. >=20 >=20 > 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 ana= lyze > > > > > > > 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, optimiz= ation > 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 differe= nt > discussion. >=20 >=20 >=20