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 DAEA942490; Thu, 26 Jan 2023 13:59:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8079F40685; Thu, 26 Jan 2023 13:59:27 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id CC2CD400D7 for ; Thu, 26 Jan 2023 13:59:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674737966; x=1706273966; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=bp5TVKZQe8WwRQLqHGKfYgL+ShV40/LZntwnAj4hw1s=; b=JsHCIqbPy5NUp8mihtQM1FevujQFKPDtTU9Fyyge9jq4TuzNZSXi28/E +VySgHElVHq8/xtTtKmY4EBx4/UOCIxtMycQ5QE+TozSMEaG8lbQzZqdS 9jfF2eNNKunykGERykM2Azs271mZwMPVkn0rof5M7ncA8TjBROuswsnnO pT4cv7gL6HDuSHo+vzCB4Wq6PlDU0hpNURbfkhPpqGmbWN6et7adKhHaM 7rMqO5pce12+ocaPF3BWYwulGZTpijDSv71Gnr1DHRPdbe3cg6OeObMFD vd90JkZhAsfzArwDAPZW7Sm8r8ESq7dO9LUXAxuaeeXkGqBhCQrbh36tc A==; X-IronPort-AV: E=McAfee;i="6500,9779,10601"; a="328053331" X-IronPort-AV: E=Sophos;i="5.97,248,1669104000"; d="scan'208";a="328053331" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2023 04:59:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10601"; a="731395768" X-IronPort-AV: E=Sophos;i="5.97,248,1669104000"; d="scan'208";a="731395768" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga004.fm.intel.com with ESMTP; 26 Jan 2023 04:59:21 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Thu, 26 Jan 2023 04:59:20 -0800 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Thu, 26 Jan 2023 04:59:20 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.102) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Thu, 26 Jan 2023 04:59:20 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iGJ6Ny3okeA9zxcYwwx6HwpL7QHxPSHjJbMqRAUr9qlPgH7u8roSe14tuhz1I1JachrrawJ8KZkEbPQ35ohDr/gGUQrKVXxLxrs/9vt2tcYFa8WjRix/zq5+fTaOQeujElH4LwOLnkmuwC7uBQAaF2FE1NzWvS3rQf7lcMH329EBkD5caZfFVHlrerD50zZHY1Eh+YMkFioIhXJYcAX3LBeM5ZISVwTpjZtZRcdrV2BzCIs87BZFIBr0uaasa/WTXNNj3IgcjmuSN8+wvex6AgPhWezBtvj3Zb5Z3iLJ51DTvG2iaotxfK1LR1wGv4jZU0Kx+yAL0uh69v6jbk6YPQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UxK0DUkbBZpu1D/CMwEUxNMIV+lZOjFTdpjI/mxj0HU=; b=oX7yCh/nAoAbdHxrZw07SjmOrU9WDy47pZgNxnUVRpon7nUIeh1gTSD9BP6kEjSbV7KDtM/OyRVH12V3GkV0jPBb1OOpcg9EBh8dFiwP7PRlx2MJsIPo0tez2KiE5kcSuMNYhnKQb9+/hqS5VVTi5Nx0S0opJsY0YI3PonZhO6nIWjLohhXVP/bxmmHbmB5NPKqG6BP/ZHePFBNYwntl0Ot/p8VSN2AbVvkGii5LavXUnwav9gRiiOLr2Wt5xguSnk5GrJEUasgS5Ixez2T4qXtBAGNa9s3ytNPGuIB7MRhQ4w8Lb6jmt5yxxXRgv9O63Wqu4wJBzgECzIw9ipVmWA== 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 Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by IA0PR11MB7308.namprd11.prod.outlook.com (2603:10b6:208:436::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.22; Thu, 26 Jan 2023 12:59:18 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::4d9f:6867:2d53:9ee]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::4d9f:6867:2d53:9ee%7]) with mapi id 15.20.6002.027; Thu, 26 Jan 2023 12:59:18 +0000 Date: Thu, 26 Jan 2023 12:59:11 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Tomasz Duszynski , , Thomas Monjalon , Jerin Jacob Kollanukkaran , , , , Subject: Re: [PATCH v6 1/4] lib: add generic support for reading PMU events Message-ID: References: <20230110234642.1188550-1-tduszynski@marvell.com> <20230119233916.4029128-1-tduszynski@marvell.com> <20230119233916.4029128-2-tduszynski@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35D8769A@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D876B6@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D876B6@smartserver.smartshare.dk> X-ClientProxiedBy: DUZPR01CA0249.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b5::10) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|IA0PR11MB7308:EE_ X-MS-Office365-Filtering-Correlation-Id: 49ea1637-d539-4609-a97b-08daff9d22b5 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: H7RfX9u82xGyxaMUrL8Yn7j7JH5QFM8uCCiZbAH3ptw+v5rNJ6UpoI0TI816KBXoZmDh6I2u6xRx5i5I+1jThKQWW80eBWCq4I14mL+QqXKGhSvD2RE2ulcNJgmQJi6TSaJUW6mUGIOTCHYCWEmXyam/hhsWQldv7HnXqoi1jNEikUdbaJhIXk0jYLly7JhadtP9styKtRZ6cvT+EWwCJdCznCI3DSlMpGhVxbe8t5g7CBR1GoRL4Gvfh9f3zh4wVqn8u9lu80nLU+ScufpFRlthMswg9JbHLGxbAod+zHtmvgsjxhxvzVNlPD0tSVgo6RZWohBuA27Gppek2f2uusUYw96ij4g3QaTDMtEboSP6PYB8d9rxVRa2gNoEmT7IoQnHTDVs47YrPmxvONb8Q1rJRIz/XpYjia5e6qPjo4nv8TwkNXd+DqXGRcD5XxUPrpJX5nnxIUhFq8N0i73gdJ/lkUOUQS73luDn0M7hoq7HT/Qz1e9FqxPIWOvE63xYBIO79dsoEirL2gUkQOyiw93K+gt+04J96a+v3MDHm1EOw7YkI4Eh08sQS7MH/tJIcCyHSYgpIg378hitt7JHfG3ZKsQBQZOTKeCrdxxuLS7xVO4FuNepy1yYQFxKVbE8U3BXKSxB0X/1s3TXoBKc9hmlv8bq0CcBelXBfYbdbTXhYXhmIkzoqwg200uYcJ7rI0IVg0iAmlXNpPvwmxJrVrY6vwVuZFI3MuMRhRfTtMfcakwaQRG8Jeeqo5l3a3J/jHOr1ektLYGlVgoSVlHtBw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(376002)(136003)(366004)(396003)(39860400002)(346002)(451199018)(5660300002)(2906002)(44832011)(8936002)(66574015)(6666004)(41300700001)(26005)(6486002)(478600001)(966005)(6512007)(6506007)(186003)(83380400001)(86362001)(82960400001)(316002)(66556008)(66476007)(6916009)(8676002)(4326008)(38100700002)(54906003)(45080400002)(66946007)(41533002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?wv9J6JIlM3fqslMVIKCFVpkJc92Bc3X9pIE+Wnh9stqNa61Q8DvLExH+Xx?= =?iso-8859-1?Q?mLJfbjcvNDMyRlQOm5HKVzYRskbR7stINlTRFio86zhqtUO+zoYmHiWqJo?= =?iso-8859-1?Q?QE1JRcU9e38hCaVJo69DmfBSNFqonVQNGtjWkgI62+fPQXFM/xUxCtfQJ1?= =?iso-8859-1?Q?jfV3y45ZqDaWGw6veHQielxpNswPKXgpddRgwcmBpfnoc0vLI9XvC3Li50?= =?iso-8859-1?Q?umfl1Ng9c8P+Yefa/SC4YYBpI3Xo40qB9j5WLBMK4IgG/mFDwVQU3tqNOo?= =?iso-8859-1?Q?yKNT/93RdDv2IW+yu07MmlU4nme4NsM3DormF7KjeGh2twVSVGKMa2J7IH?= =?iso-8859-1?Q?fyMgxFXinNWlLybFD2j5pp+rdUbjbQi6LbWL9fxLWbui08i6fRlLFCtfy3?= =?iso-8859-1?Q?v24D2S04xZjGEF1m73OLntLsaEij41RQPwb1SG+S/b3E1p7/BPt/qs/7K7?= =?iso-8859-1?Q?dA+3ZR614uDGCrvCArEEeniO+5J8CNFaZ2QXoRDZX/SPJVa7rzNmWld6d0?= =?iso-8859-1?Q?pjrUZBr4T1FjiGPkwSAbNDxgYyM+XxWLKqIPKmjovrkbL5ZlfRwjAbff9/?= =?iso-8859-1?Q?yzsz4HYDPCX435WbTw/PBjuyHnjvqi1swfOvv/leYmVIB80pcznZE3jaBg?= =?iso-8859-1?Q?wK6zA3y5ifqTQY0kSyWQ3kk5yh2hpFT5+R950KkyF7Jwhyy4LNVs5lnKB7?= =?iso-8859-1?Q?lGOV31++6Fleh9W8aCY28d4lAm86dcMZOo1Aw8bKPcZeTCqm6Z+FIGdHdq?= =?iso-8859-1?Q?vns41WrduyJZte7dqPq+6tYoKXrU57ZfKamNCa754V1lccQ4RH4PLYv0CU?= =?iso-8859-1?Q?QXPKSlyz2fTfYurdavQQXU1BAsxOzOhPSq+g+rtkvejuWAPccoLK2Iv9ml?= =?iso-8859-1?Q?qzsMOmRW1s7fKRaDE6PfIwRFT7I3UKnjrbs/+kRPiAQn0/O0YkeEnmgtHJ?= =?iso-8859-1?Q?grkbaKgRcLeKYjYEaEQcN21oYXKjxW9SBxGFuXtrdYfPoQmyC2naskpnIl?= =?iso-8859-1?Q?F+iik0L8vRF3rFttzWwwEFAZb9atuXoBJhfM/MRwM/WnkdeGPkA7Vjp8j+?= =?iso-8859-1?Q?pzIPO88veufw5P3Fl3kMX/r/ao9Rs5s4U6HMJ/Ozq9JawW/09f3km8D/Nk?= =?iso-8859-1?Q?UyvTwa/uJiJiYraz4B0iXm6uO07j6dRVyx0n6uFqNVlhbA3YVskCmxUy0i?= =?iso-8859-1?Q?jivd5Fi4RxzAdJzCFl7iih0MvjFCYvofDWvYkP+pN9oi/LwlU8Cs6KaxnO?= =?iso-8859-1?Q?o2Bhp6jPLdghsw/q2encYzlnwUEH/C4Vyv2GQMZiSQhh6F5Xnwzs7P0fqG?= =?iso-8859-1?Q?qWSQMTtd+0GMW7Vi0tR8tiXbVoyGr74ctQULmlBhNHj5jnS0Kc50ycpdnt?= =?iso-8859-1?Q?8ZY4pdSRPzC8tskEfwLcTC9UusrByE+pcYZ3hPqXezlYl61jzMfzZISl+X?= =?iso-8859-1?Q?jhpdUfV1y5X9RnwaTsVDDeFmoXfMBbQ0cV81Z5f36F/RtIFiBx50IYm2uc?= =?iso-8859-1?Q?Ra0qOhfL3lPLeR7bFio8lSGDdLIBkmwG+/+jwIk6Hn/sEdCTSMaZklKV9K?= =?iso-8859-1?Q?cww07XORgskHuczPiRjSe3EKFOWz2eJPaNsSSBOCYUu7h/CA9HqiiU4Irr?= =?iso-8859-1?Q?NcQjYveS9JvMqryCbZ80VeIJaH06y0w2aWUQuogfoaRabzcqqfkqYAwjPH?= =?iso-8859-1?Q?zwyDdWCBaNPueKQNZgc=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 49ea1637-d539-4609-a97b-08daff9d22b5 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2023 12:59:18.5657 (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: 7P+Igy2QVUj3rENwEopVGNVKSovpM+XhJKfCt7MiQXj0be/bDM67MmJnnonZ4zl9XqmqLE45ZX6IvoctgBw8aaOpNDZwJBn5zgRSP3YPfEc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7308 X-OriginatorOrg: intel.com 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 On Thu, Jan 26, 2023 at 01:29:36PM +0100, Morten Brørup wrote: > > From: Tomasz Duszynski [mailto:tduszynski@marvell.com] > > Sent: Thursday, 26 January 2023 10.40 > > > > >From: Morten Brørup > > >Sent: Friday, January 20, 2023 10:47 AM > > > > > >> From: Tomasz Duszynski [mailto:tduszynski@marvell.com] > > >> Sent: Friday, 20 January 2023 00.39 > > >> > > >> Add support for programming PMU counters and reading their values in > > >> runtime bypassing kernel completely. > > >> > > >> This is especially useful in cases where CPU cores are isolated > > >> (nohz_full) i.e run dedicated tasks. In such cases one cannot use > > >> standard perf utility without sacrificing latency and performance. > > >> > > >> Signed-off-by: Tomasz Duszynski > > >> --- > > > > > >If you insist on passing lcore_id around as a function parameter, the > > function description must > > >mention that the lcore_id parameter must be set to rte_lcore_id() for > > the functions where this is a > > >requirement, including all functions that use those functions. > > Perhaps I'm stating this wrong, so let me try to rephrase: > > As I understand it, some of the setup functions must be called from the EAL thread that executes that function - due to some syscall (SYS_perf_event_open) needing to be called from the thread itself. > > Those functions should not take an lcore_id parameter. Otherwise, I would expect to be able to call those functions from e.g. the main thread and pass the lcore_id of any EAL thread as a parameter, which you at the bottom of this email [1] explained is not possible. > > [1]: http://inbox.dpdk.org/dev/DM4PR18MB4368461EC42603F77A7DC1BCD2E09@DM4PR18MB4368.namprd18.prod.outlook.com/ > > > > > > > > Not sure why are you insisting so much on removing that rte_lcore_id(). > > Yes that macro evaluates > > to integer but if you don't think about internals this resembles a > > function call. > > I agree with this argument. And for that reason, passing lcore_id around could be relevant. > > I only wanted to bring your attention to the low cost of fetching it inside the functions, as an alternative to passing it as an argument. > > > > > Then natural pattern is to call it once and reuse results if possible. > > Yes, and I would usually agree to using this pattern. > > > Passing lcore_id around > > implies that calls are per l-core, why would that confuse anyone > > reading that code? > > This is where I disagree: Passing lcore_id as a parameter to a function does NOT imply that the function is running on that lcore! > > E.g rte_mempool_default_cache(struct rte_mempool *mp, unsigned lcore_id) [2] takes lcore_id as a parameter, and does not assume that lcore_id==rte_lcore_id(). > > [2]: https://elixir.bootlin.com/dpdk/latest/source/lib/mempool/rte_mempool.h#L1315 > > > > > Besides, all functions taking it are internal stuff hence you cannot > > call it elsewhere. > > OK. I agree that this reduces the risk of incorrect use. > > Generally, I think that internal functions should be documented too. Not to the full extent, like public functions, but some documentation is nice. > > And if there are special requirements to a function parameter, it should be documented with that function. Requiring that the lcore_id parameter must be == rte_lcore_id() is certainly a special requirement. > > It might just be me worrying too much, so... If nobody else complains about this, I can live with it as is. Assuming that none of the public functions have this special requirement (either directly or indirectly, by calling functions with the special requirement). > I would tend to agree with you Morten. If the lcore_id parameter to the function must be rte_lcore_id(), then I think it's error prone to have that as an explicit parameter, and that the function should always get the core id itself. Other possible complication is - how does this work with threads that are not pinned to a particular physical core? Do things work as expected in that case? /Bruce