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 15ECA42493; Thu, 26 Jan 2023 16:28:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A3C0F41181; Thu, 26 Jan 2023 16:28:32 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 799A940223 for ; Thu, 26 Jan 2023 16:28:31 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30Q9tXBW007278; Thu, 26 Jan 2023 07:28:27 -0800 Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2108.outbound.protection.outlook.com [104.47.58.108]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 3nbn7223qx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jan 2023 07:28:27 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ej98IzesAOXHPRFkeSuvblSUyJYQWFmEk8cKkz+O9Nc/4dY3rY1gpj8n/O+Bk8ANER+rQ+wR432FMB/gN49NmUePQRGXgFBBoYPjNrx8eIssQOHv19KuP7I/3OmndJHsOkzFcaFljbuOg8bnClFNUzI1IzMII5oIYhHRdhWdOKM9x09Ix03gEu0NnrLwOXkZd5jHisXrg69E9/cOMQeiduKLvZYbc8eyek/BpbKgvWp5+iea4vBJov+TFKW8vIDlTNmmRoNlwvUd5gVwfqtVRjbUGBW5iFWWmifTmAAgltzD+OnxMGkn8/qyISmGo7ZIQkmeWo/snEHp+xdOiTmjOA== 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=UsxKYaUCLZ9tekXawgeE9Brv4b43Xo51Y/HQXYh6Faw=; b=RD2Xb0iAQ0Pf9MSGj4sJO4HkdXtVYZyrby6aIlklPeL22UtxAJ2sdGpDJbWtEsZ+NcmUpY/oF8a7DxFSV2fOPrD30eI2E96MJgKcRBOm083Rnp47jc4WHOvX6gfXb5PXVE1Y3VswYx0djxBo3u1z+5bnjSSMtHBuK20LrxvtKlm0M4OrYU5Vs89cPYcNLT/Y8VFeDuV5jywkL5KPytIWwpLCIhpbnNzPYaEKVX+agnM7vDB7ifBxg+HbxB+2bnzZFBE93CwhtqZB3T/Y2dnym+rq72lneqXe1pWSXy6N4zEQo4cASezeWEJtdyMokhIJs3s23HKAm5IQw0/etU+bdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UsxKYaUCLZ9tekXawgeE9Brv4b43Xo51Y/HQXYh6Faw=; b=mSOCLNeZ1g5Ss+bVRvnQtxrx1IS5x+tzMZbbnBtHonr5L7WXbAJNhUx7jTKIokW3q5gxccYUdNvPElydvyrppUnrPKdFZJteoqIZrIpfkGP8FwwOzMYbPGev8WcKLxylG3niq2YCot3JbJIUYZPmkg/Z7TggK3zUCTG1Fj8IC+I= Received: from DM4PR18MB4368.namprd18.prod.outlook.com (2603:10b6:5:39d::6) by CO6PR18MB4019.namprd18.prod.outlook.com (2603:10b6:5:34c::6) 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 15:28:24 +0000 Received: from DM4PR18MB4368.namprd18.prod.outlook.com ([fe80::3117:f51c:37c2:fa05]) by DM4PR18MB4368.namprd18.prod.outlook.com ([fe80::3117:f51c:37c2:fa05%9]) with mapi id 15.20.6043.021; Thu, 26 Jan 2023 15:28:24 +0000 From: Tomasz Duszynski To: Bruce Richardson , =?iso-8859-1?Q?Morten_Br=F8rup?= CC: "dev@dpdk.org" , Thomas Monjalon , Jerin Jacob Kollanukkaran , "Ruifeng.Wang@arm.com" , "mattias.ronnblom@ericsson.com" , "zhoumin@loongson.cn" , "roretzla@linux.microsoft.com" Subject: RE: [EXT] Re: [PATCH v6 1/4] lib: add generic support for reading PMU events Thread-Topic: [EXT] Re: [PATCH v6 1/4] lib: add generic support for reading PMU events Thread-Index: AQHZLF9HxL6yMLPInESeqtNvHMF+j66nD34AgAlimuCAACzbsIAAFEaAgAAmzIA= Date: Thu, 26 Jan 2023 15:28:24 +0000 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR18MB4368:EE_|CO6PR18MB4019:EE_ x-ms-office365-filtering-correlation-id: ba6463a6-5bc3-42f9-bc1d-08daffb1f6d4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7PPRHe+tOfshlGoUP8vpEOQxpSifLXc/loSI3Af6JifF08f2clQ0tP3t3nUzeS4YDBkDGob0mXvyITOO84bC/pzWg+h3y6rfbt0SYEhogslSHUf9PxBTDDave+eIuQLfeRBsGrvUjFelwyZIRMSZSu5ydowFtXkNEewS94gc1IJO3Zel3Qnx9k1yNCQDPvQb6J24oRSTR2PABWdC7jacLQPTFwJXzT5QNOO8YLUyVOE6ebyLoCN3mQz+WER1C4JG9l4g8Ou+D+yW4d+1pnei1aGaWLwoPS06xKmzVrcuRd+2yWBol9ECX5slL/x1FPp1Z92fjfRHyY6wkI9E9Q+7ymSQPna5y1cCR0sUHnf8H2icAyJgKUTUjxFw3fh+KtLR9KzqNCE5focim9QQ74aCs6Hw6glUQtcxf9X3tYZYk3DwHhbwnOprU6ANeFWPWRLOl5qvE8oEUrSrrKBq1LeFidI67dc0FCHlyVZ6WYwMTZuB04NdwTp1dMdlMZOKpvnzxwJJfFa8DZ5KHhGILqQDkL/WnnFJoqr83mxXhumcrZTl1UGx3KzOz7Zx7gcYhXWIksZ5v8T9pWR7Au8V44sItZO/P0AhPSdSfEPBiEYRtGKvNm+z77ZpE1268SvwosVpKw2hvfbxlthUBawNzD8t0sy5C5S+SShByW1VsvcibpSyPjVebr6Qw/iad3h2ScuidCCcuf9S8hj8WR62jYoCN1CKUYxMg4GmpfMimoeQk9oDtw2trTcfMoWRHxrsonUw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR18MB4368.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(346002)(376002)(39860400002)(136003)(396003)(366004)(451199018)(64756008)(316002)(54906003)(110136005)(122000001)(38100700002)(41300700001)(8676002)(76116006)(66556008)(66946007)(66476007)(4326008)(5660300002)(86362001)(8936002)(38070700005)(52536014)(55016003)(2906002)(6506007)(19627235002)(66446008)(33656002)(9686003)(26005)(186003)(966005)(478600001)(7696005)(45080400002)(66574015)(83380400001)(71200400001)(41533002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?9wNqc1FPDlHhWMUrPSSOg/cBQhPlJ2scNUxitWUAQiJD4QiAMxN9AzgeUt?= =?iso-8859-1?Q?apcPvaCDWSlUIzydZ2vHxzrDjQhNMQ3CakWTf4PVYujOtKNJ6UPY8FQlB1?= =?iso-8859-1?Q?Z/OH95Lz5tmfsnxnWg2jCBXJHkWWcSUzD4DO/BHAZ9hCXEi4399RMVC7bh?= =?iso-8859-1?Q?5N1CtN0zcnc5cgsgraUhITOKVCMZS6130HEa+YHnMOnXP7zRLdrwV3sqRY?= =?iso-8859-1?Q?oMOMjn0anma6bEXcGkpLtNYL4tEaoHTt6KDaad080Nz+UNtOAG5O+xvtZ0?= =?iso-8859-1?Q?EzVPmuDu61Y1B2VPcvxnkAYVqHWFP0geA3VNj1SeCbm4Q+m1vNYaKtEnoI?= =?iso-8859-1?Q?sQR72WczGpEYdDXXA0zs8OkXjhxBHsmsT0gL7KrGMpzPlvTtcd59p5nIJY?= =?iso-8859-1?Q?xZdgtXwQgDacvlc2lymj+4zMwJdYOrGyBn0mXEH8xowVI6TZ1Jusidl2tF?= =?iso-8859-1?Q?SJHNh8Fqx2DaWyUQ5oT7gchiyEfHGUnp1VBZQ9Ga3UzWPf4sSOTeo4gOAj?= =?iso-8859-1?Q?P8EE44ALT7u+VX72bPyb4qDgY2ANtgXAnau0Of+JM6w+sUgkZfPsA+/z0u?= =?iso-8859-1?Q?gn3oVfvdi3yRE4EM4X5D/b1s+rgwFIEgZUywgwKdmU/tT3306IuvV8weng?= =?iso-8859-1?Q?b1MzTfTxfQsIoG+pYmbUobLs+ydq816cDES6AzDBR/gPp9kKIJD5AYX1HA?= =?iso-8859-1?Q?HpBa4tUm5m1APYkc71D8ibxD6c0HifVC9/BuJh2mxi1Pi03qw4RUOnvF78?= =?iso-8859-1?Q?jFcm1L0yFpPApeD7B/8Gjy7N6X+ohzJ3Crz3a099/K+xJu03VCwG1pcdWT?= =?iso-8859-1?Q?f3PR0oB8cTxL12ETsUUH4cQ4VrwYt9Z7CxWVeWoX7aFI5togcOOofVunZo?= =?iso-8859-1?Q?/ndmI2AGPR3hSZTuTR1pKKpeQsepDNN2ekT/jNHqe6UWmmrqsFlwNYQZja?= =?iso-8859-1?Q?+7mDenIeomDkCJV/2JGmNDNJRpWLo2yHDJd3x7+/vl43Kmyh/IErMShLzL?= =?iso-8859-1?Q?4vkJlmYTQfaFPNoUVXVK69+TUPr047+ac5/zx4kw0tqilFT5YEocD8BtNX?= =?iso-8859-1?Q?SjJSDv24yg71tEZFpbj8VKf2yCiWfOpYlb3AXnjEfju1K0wrAyHnYKOwlt?= =?iso-8859-1?Q?8EWL2FD5EittsVd+yyw3uMhh9iLWkfpQUJCwY/tNj9GIv+rH6ukn61ppOL?= =?iso-8859-1?Q?TBz42IqTMWARqmzeXBXdmuclzT7fzVNwEmyek4EA7eVSd8IELh90LWPk4q?= =?iso-8859-1?Q?VltmFgYajLgOYGG6uA2YEHE6dfKhkK3M7WtZ7O+j/HZ/Fu9hTKHj+9lWrG?= =?iso-8859-1?Q?Gtb0j5HuhcWMSAnR71DO24ZRyTeFQe+unRo0oc0XXsZerOTF35DsjTNMXb?= =?iso-8859-1?Q?MSCcFgHOyn3dz1FWnLY5iW7ZLA7viv7VVbp1mv8Gn0E2ZJlUIPqDXirTHe?= =?iso-8859-1?Q?f4ILuF4L6VHi5Roa8+sjQRdxD/Xgb44LrRYrCS/gwQSBRstBCit+8oVrCj?= =?iso-8859-1?Q?lKj+TgANmeFxQ1LCEbDbhXrkM5qakjH+5Li16salhp0LmGfj8RdlTVoH6r?= =?iso-8859-1?Q?hYNIXqyRpUXxwqx1AZJXBDJZD5KFJsJeWR4Pnib8miPk1QClp9+kTJXqCo?= =?iso-8859-1?Q?TLzWSYth0ykO6P1q+Gbf4goKjB4jOWmQpW?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR18MB4368.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba6463a6-5bc3-42f9-bc1d-08daffb1f6d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2023 15:28:24.1621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7Gl42XUgeELkKD5dAj1Q03HFrhPXNIeidVIltGAqwjTd8QfBO9lTa2nP5P/+WR3N8R6OQLPgjgpS4AwoB+fhiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR18MB4019 X-Proofpoint-GUID: uc4AIvZAzzcALI67X6z4rDG9zQDRYJmu X-Proofpoint-ORIG-GUID: uc4AIvZAzzcALI67X6z4rDG9zQDRYJmu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-26_07,2023-01-25_01,2022-06-22_01 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 >-----Original Message----- >From: Bruce Richardson >Sent: Thursday, January 26, 2023 1:59 PM >To: Morten Br=F8rup >Cc: Tomasz Duszynski ; dev@dpdk.org; Thomas Monjal= on ; >Jerin Jacob Kollanukkaran ; Ruifeng.Wang@arm.com; >mattias.ronnblom@ericsson.com; zhoumin@loongson.cn; roretzla@linux.microso= ft.com >Subject: [EXT] Re: [PATCH v6 1/4] lib: add generic support for reading PMU= events > >External Email > >---------------------------------------------------------------------- >On Thu, Jan 26, 2023 at 01:29:36PM +0100, Morten Br=F8rup wrote: >> > From: Tomasz Duszynski [mailto:tduszynski@marvell.com] >> > Sent: Thursday, 26 January 2023 10.40 >> > >> > >From: Morten Br=F8rup >> > >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 ca= lled from the thread >itself. >> >> Those functions should not take an lcore_id parameter. Otherwise, I woul= d expect to be able to >call those functions from e.g. the main thread and pass the lcore_id of an= y EAL thread as a >parameter, which you at the bottom of this email [1] explained is not poss= ible. >> >> [1]: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__inbox.dpdk.org_dev >> _DM4PR18MB4368461EC42603F77A7DC1BCD2E09-40DM4PR18MB4368.namprd18.prod. >> outlook.com_&d=3DDwIDAw&c=3DnKjWec2b6R0mOyPaz7xtfQ&r=3DPZNXgrbjdlXxVEEGY= kxIx >> RndyEUwWU_ad5ce22YI6Is&m=3DwEvFmuH_S_EhAgRZQTC7z3pQ1Sr_cEsbFAXxgE2Fi2ESd >> 4sMgg-tgVOVDepp-JYO&s=3DwU4g1LLV4EHyRYpj2inWOK8MDcUKq7txrZ7RXZhUM2I&e=3D >> >> > > >> > >> > 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 ins= ide 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=3D=3Drte_lcore_id(). >> >> [2]: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__elixir.bootlin.co >> m_dpdk_latest_source_lib_mempool_rte-5Fmempool.h-23L1315&d=3DDwIDAw&c=3D= nK >> jWec2b6R0mOyPaz7xtfQ&r=3DPZNXgrbjdlXxVEEGYkxIxRndyEUwWU_ad5ce22YI6Is&m= =3Dw >> EvFmuH_S_EhAgRZQTC7z3pQ1Sr_cEsbFAXxgE2Fi2ESd4sMgg-tgVOVDepp-JYO&s=3DAyyj >> pEtATWUHfWnGMn5j2XDLMjgxxJTh5gQV0m77z5Q&e=3D >> >> > >> > 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 =3D=3D rte_lcore_i= d() is certainly a special >requirement. >> >> It might just be me worrying too much, so... If nobody else complains ab= out this, I can live with >it as is. Assuming that none of the public functions have this special req= uirement (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 fu= nction 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? > It's assumed that once set of counters is enabled on particular l-core then= this thread shouldn't be migrating=20 back and for the obvious reasons.=20 But, once scheduled elsewhere all should still work as expected.=20 >/Bruce