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 BC984A0547; Wed, 29 Sep 2021 13:47:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25BBE410E5; Wed, 29 Sep 2021 13:47:16 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id A8B1E40685 for ; Wed, 29 Sep 2021 13:47:14 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10121"; a="288577700" X-IronPort-AV: E=Sophos;i="5.85,332,1624345200"; d="scan'208";a="288577700" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2021 04:47:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,332,1624345200"; d="scan'208";a="588000195" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga004.jf.intel.com with ESMTP; 29 Sep 2021 04:47:00 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 29 Sep 2021 04:46:59 -0700 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) 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; Wed, 29 Sep 2021 04:46:59 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Wed, 29 Sep 2021 04:46:59 -0700 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (104.47.73.45) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Wed, 29 Sep 2021 04:46:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QDjGuvlVUs/z+R+O2MrxS9Es1paPJOt18XmGWreqozbXbIvRkyDWK2bpERJHIbNGSHQ86J25XHYByKZyL38yqQLocJYDklLFGfQx1M1aH2OF/oUKvd7gLZy6X/E0Ytmgd6cxbzIgzVTOK4H61+iNjopOyKh9XJsDLwI1O9RUNwN/TbIlxZozxH7DZdQJ2/Cc8OG/5NihcCdve5O8IwgRwmxardeAip7NpCxGj3g1Dy9E/ttB5weW1rQJLWojsa/Tl1fBcaXF2QHOqZFjYSZOKYZcOT+knNMn+2ssbRDJt6AupYkqhapvyLezmFW69VTheUM7qN1sUdGAO0TYbbDOGw== 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=U+3jlJ4l3E9tTdKck/U7dHaJSuLIbKQiFAUhEvWu6Tc=; b=TXX4PK1XtxhfxSQUH9if1gJzKZnCaQAr/tHwkF/tr/xZvj7CW3wSfkX75Kte0hvCowGoHdYRhiiFtMohR4QTLxC7CZFFllvcFWX6Ca73+Jzd7S3JVwWD2HMbSYWgj9EV68zA7W3GeAuPJN+0c5k7upkkwFyoXNAhNnt2eDdkvjIHlhC9vr0vgMTzK8diZuoeqZm029onkIyDJCgqRInLnA+WT5Dzm9VgIe8Ag8rpECoY9EGw6J2oy1pbi5xrz05Dfo/COIB727Drv/IVHtW191C1nLgMa3Up4wA/5qsQcm3IW3RECkjJjQr+Sj0qvOv/AgAsjNV+zSy0aCJuBHjGZw== 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=U+3jlJ4l3E9tTdKck/U7dHaJSuLIbKQiFAUhEvWu6Tc=; b=GnRF9tll2n98HbiG7zZ+hZe9/NoU5kNZe30hl8eSvcdzvPd1x7ZqRCvOnXSwpbjpKP/mRkpzbKKaA7hAoUCojCd0GCMkCXpOyPNkmhRL8VXsv30QXCMd9I7PIaJ0+l3mTxS/SivVgGr+jAqzRoksvgeDtt5q+7R/UM4NxEB7vno= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB2633.namprd11.prod.outlook.com (2603:10b6:5:c0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13; Wed, 29 Sep 2021 11:46:52 +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.4566.014; Wed, 29 Sep 2021 11:46:52 +0000 From: "Ananyev, Konstantin" To: "Richardson, Bruce" CC: "Xueming(Steven) Li" , "jerinjacobk@gmail.com" , NBU-Contact-Thomas Monjalon , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue Thread-Index: AQHXjSWyH8VFYJkIWkOxWCsDakefPatt9JUtgABDWZOAR96KAIADZ48AgAAiN4CAABZsAIAAB6SAgAADvQCAAASrUIAADHMAgACDXqCAALOSgIAACLsggAAXR4CAAAkvMA== Date: Wed, 29 Sep 2021 11:46:51 +0000 Message-ID: References: <15b1590a8899d85e85bb4f7c104b9399654ee160.camel@nvidia.com> <543d0e4ac61633fa179506906f88092a6d928fe6.camel@nvidia.com> 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: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebfff6d5-95ec-4246-78c4-08d9833ed430 x-ms-traffictypediagnostic: DM6PR11MB2633: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aasrLtsYolBhD8mKA2B1+mo7br4NJbdsgxr3fnRzFxMHxtv5FUe3abfxsvhamEU3UhlVJroRvKE68vl9o/BpLbXvlb2IlVV+ui09OwbRR0jMCovYnm0i/9AeTEQVG0yM0dDMU9PdChtoNyMoXH6vb9ojByw5MgkrznODSYtlu0l/vxRGPDd4pRye/YU4yrDUtqYHSmCfecuTMup3aHCG0MXefHdC+9jvYU+o1T8k9BZVzL/8UYdndijUZDWEzeQhD08SxQALEykyZrz4rIUxeYot58e4clB2ojOovd0zSR9NoBPHUDQYhz0KAr1h/mpK6yEFERgsGRWYr4N60Wl7UIuyzgHaVy0jm542mlIO/zQ3/XXywpCnTW5uzAOEOjS35q7H/IRFCSQXU9KDqi7f5misiNUjwO1o6XJKmwURQjDZh1LoaZJTpaFYquBqyrAt26vN3CTWnJ+wVzx5zsBbbCZrP/vECfUwC1v+DGJryQwd/nLTB49MvgTeHLhQEEIFYcxzIMPWvcjft5uSz1V2Ky40kGp2t9GbDZGODcenPIFF2tMVuQsdv69Ow178UTmdT+6ufAhuqxum+HlsMFMoMm5x0YvkFYfW84GaA5frCf3wODUESX7ZOUGY7YLkszm+Hw4DhTlxSI2HJKRj7lP0AifrgRqgCeRX1d9XxTTvXcR8iYwFq8udPDZp9MPfXN7W+8wmVhPDyR/OiPXxHC6vQfG4yV4kU2QypYAJf5Tx+kFcjrQ94kQfUyoyurZc+l8uIwf7JLfiJPZ3i9gVXnwfa6wy1o3ndaT/xrvGq3LyeTs= 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)(122000001)(55236004)(107886003)(71200400001)(54906003)(4326008)(5660300002)(26005)(2906002)(6862004)(316002)(38100700002)(52536014)(33656002)(186003)(83380400001)(8936002)(9686003)(966005)(66946007)(66446008)(64756008)(66476007)(66556008)(7696005)(6506007)(53546011)(8676002)(38070700005)(508600001)(55016002)(76116006)(86362001)(6636002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7tVizfzABFKEW07hni3IC3dkba1flD7Z3mcRGdkyZyNLmXmOtskM/GfMvJvc?= =?us-ascii?Q?3czERx5GRVcgB0j6udXWY9vuHQ0FSzQgF6lyaZNcvT4vgGYV5rDCxhePuwwL?= =?us-ascii?Q?T/Bb8jvgCfUIDoxW/LaGwS//k5Oq1sbfsdauy0bfFotQDMWgW5h0NXTZ08TS?= =?us-ascii?Q?/S5doCGyQroWhg6eB9IpxC2gHT05AxRtako8YVqaX8DHHPj2Dc2YAPR/gf0E?= =?us-ascii?Q?DfSLdqkV4N1vKDZhH/OMbtSGPIDXnPXSLKBjlmF01aBUPB1PTldYGtZ/mfZY?= =?us-ascii?Q?1EwlTOUjgxvC9IxghIvNHGg7IDbx6iNEDXu7ZzDpt/jshDMvXYUit9c3rBnQ?= =?us-ascii?Q?+j85nWhytckEedeFkUfc29r44xUHCaif1i5KwCKQbwnCIovgv0vroV5qQaOe?= =?us-ascii?Q?WVS5HKDPgOWJTifNDdNZ+iiexeEuvE3gN1WQ9bviO4J5nEwYDnJkg3iBIo1d?= =?us-ascii?Q?hd5zXRBrHH1l13eI5FkM+r2Z922I2lO8xO9QcAC4Ti9sWebijtlbmRe1JsTI?= =?us-ascii?Q?PCiR/puydVzUjh+j1E4b9OeVHHoZVuZu+iCm2aghjl+TerXGKD8Ghl7O4qaz?= =?us-ascii?Q?IGykDe5XqfejflDfcGLZoMrlbeZhFbN7xcUp5kE1cSh8AUbVn2Rv8FjfAcY1?= =?us-ascii?Q?GbSH/uHhmIRZgLr1aDrrT8Ike1pjohIwQiNcMobiTKNaOd1ej16yYuhsz5Pu?= =?us-ascii?Q?ntaJ2S3N/sSt30BY59kHnzNtCbbkTynQhWWdymg56EuJrh0DyANlWKEx5Xcz?= =?us-ascii?Q?4L4/TVWJ0jMwmQxUPsCL++X5D95BXuilD44+WzdC2MmjDfZbbihyAAbD8OUL?= =?us-ascii?Q?gOBDCMzv+WwVoqBCBGhVrUoGHTPWW93kTqgTi5FBaeq+twcKR8pxM1qPJIvL?= =?us-ascii?Q?CUJku7Tv18SBcMTv57P6QlwtGtdXL27rdWzxKUBFiiwMCaVifooSTduigxWS?= =?us-ascii?Q?AmHUtZiyKkX7ztqJdpiC+6CjhjYbYYFVLF89fhq12jrKyLRf6n5kj6rFbIDK?= =?us-ascii?Q?2MlZIBHCt/dpniQBhCD7qxtM19z19oF0aDajDoOJ/Wo7UmAxHdnHPpHHcRVi?= =?us-ascii?Q?EBiTdLJg8cQrraIE0CZuCKevR5QcFgNNte+gH6tGvrHRS6/pCOOtMf40YicX?= =?us-ascii?Q?82T2BgmU2umHwhhKZKme7/LbGMiMWK5WoOFUDp0y/a8BXfIckEwNUu2Gs2+W?= =?us-ascii?Q?se6pETbNzKTjkNKs9BWvKSNdYTZBttSUZyRlK3sCbmOUh4M0PMm2ZaRbOXyd?= =?us-ascii?Q?Ntd9Rnh8EZudHcrVHj+f7DmM8jcWmyfQG34tcP4WqUjlrf17zdPwrGckU+tP?= =?us-ascii?Q?+h85E1jVpNqT9oJNFA1GCrBq?= Content-Type: text/plain; charset="us-ascii" 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: ebfff6d5-95ec-4246-78c4-08d9833ed430 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 11:46:51.9823 (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: 7kJ6vsQvwloPuqdpcoEW6TR0y6JUzzpLdhpYTMzALsH32wwd/GBbXbAag6n9Ze/BRhv9zrp3q0wX8HX+4CvQR6fKSeDqnsR0OwP+o7OA7bw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2633 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue 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" > -----Original Message----- > From: Richardson, Bruce > Sent: Wednesday, September 29, 2021 12:08 PM > To: Ananyev, Konstantin > Cc: Xueming(Steven) Li ; jerinjacobk@gmail.com; NBU-= Contact-Thomas Monjalon ; > andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; Yigit, Ferruh > Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue >=20 > On Wed, Sep 29, 2021 at 09:52:20AM +0000, Ananyev, Konstantin wrote: > > > > > > > -----Original Message----- > > > From: Xueming(Steven) Li > > > Sent: Wednesday, September 29, 2021 10:13 AM > > > > > + /* Locate real source fs according to mbuf->port. */ > > > > + for (i =3D 0; i < nb_rx; ++i) { > > > > + rte_prefetch0(pkts_burst[i + 1]); > > > > > > > > you access pkt_burst[] beyond array boundaries, > > > > also you ask cpu to prefetch some unknown and possibly invalid > > > > address. > > > > > > Sorry I forgot this topic. It's too late to prefetch current packet, = so > > > perfetch next is better. Prefetch an invalid address at end of a look > > > doesn't hurt, it's common in DPDK. > > > > First of all it is usually never 'OK' to access array beyond its bounds= . > > Second prefetching invalid address *does* hurt performance badly on man= y CPUs > > (TLB misses, consumed memory bandwidth etc.). > > As a reference: https://lwn.net/Articles/444346/ > > If some existing DPDK code really does that - then I believe it is an i= ssue and has to be addressed. > > More important - it is really bad attitude to submit bogus code to DPDK= community > > and pretend that it is 'OK'. > > >=20 > The main point we need to take from all this is that when > prefetching you need to measure perf impact of it. >=20 > In terms of the specific case of prefetching one past the end of the arra= y, > I would take the view that this is harmless in almost all cases. Unlike a= ny > prefetch of "NULL" as in the referenced mail, reading one past the end (o= r > other small number of elements past the end) is far less likely to cause = a > TLB miss - and it's basically just reproducing behaviour we would expect > off a HW prefetcher (though those my explicitly never cross page > boundaries). However, if you feel it's just cleaner to put in an > additional condition to remove the prefetch for the end case, that's ok > also - again so long as it doesn't affect performance. [Since prefetch is= a > hint, I'm not sure if compilers or CPUs may be legally allowed to skip th= e > branch and blindly prefetch in all cases?] Please look at the code. It doesn't prefetch next element beyond array boundaries. It first reads address from the element that is beyond array boundaries (wh= ich is a bug by itself). Then it prefetches that bogus address. We simply don't know is this address is valid and where it points to. In other words, it doesn't do: rte_prefetch0(&pkts_burst[i + 1]); =20 It does: rte_prefetch0(pkts_burst[i + 1]);