From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 8BF5541BAE;
	Thu,  2 Feb 2023 15:27:45 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 6CC7942D20;
	Thu,  2 Feb 2023 15:27:45 +0100 (CET)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id CD0CA40EDC
 for <dev@dpdk.org>; Thu,  2 Feb 2023 15:27:43 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [EXT] Re: [PATCH v6 1/4] lib: add generic support for reading PMU
 events
Date: Thu, 2 Feb 2023 15:27:42 +0100
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D876F6@smartserver.smartshare.dk>
In-Reply-To: <DM4PR18MB436868DA3F47B766099535D1D2CF9@DM4PR18MB4368.namprd18.prod.outlook.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [EXT] Re: [PATCH v6 1/4] lib: add generic support for reading
 PMU events
Thread-Index: AQHZLF9HxL6yMLPInESeqtNvHMF+j66nD34AgAlimuCAACzbsIAAFEaAgAAmzICACu6BgA==
References: <20230110234642.1188550-1-tduszynski@marvell.com>
 <20230119233916.4029128-1-tduszynski@marvell.com>
 <20230119233916.4029128-2-tduszynski@marvell.com>
 <98CBD80474FA8B44BF855DF32C47DC35D8769A@smartserver.smartshare.dk>
 <DM4PR18MB4368F56191E422D51FEC76B5D2CF9@DM4PR18MB4368.namprd18.prod.outlook.com>
 <98CBD80474FA8B44BF855DF32C47DC35D876B6@smartserver.smartshare.dk>
 <Y9J5H7kW/jnH+Eih@bricha3-MOBL.ger.corp.intel.com>
 <DM4PR18MB436868DA3F47B766099535D1D2CF9@DM4PR18MB4368.namprd18.prod.outlook.com>
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Tomasz Duszynski" <tduszynski@marvell.com>,
 "Bruce Richardson" <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>, "Thomas Monjalon" <thomas@monjalon.net>,
 "Jerin Jacob Kollanukkaran" <jerinj@marvell.com>, <Ruifeng.Wang@arm.com>,
 <mattias.ronnblom@ericsson.com>, <zhoumin@loongson.cn>,
 <roretzla@linux.microsoft.com>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

> From: Tomasz Duszynski [mailto:tduszynski@marvell.com]
> Sent: Thursday, 26 January 2023 16.28
>=20
> >From: Bruce Richardson <bruce.richardson@intel.com>
> >Sent: Thursday, January 26, 2023 1:59 PM
> >
> >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?
> >
>=20
> It's assumed that once set of counters is enabled on particular l-core
> then this thread shouldn't be migrating
> back and for the obvious reasons.
>=20
> But, once scheduled elsewhere all should still work as expected.

Just to elaborate what Tomasz stated here...

The patch contains this line (code comments are mine):

return syscall(SYS_perf_event_open, &attr, /*pid*/ 0, /*cpu*/ -1, =
group_fd, 0);

And man 2 perf_event_open [1] says:

pid =3D=3D 0 and cpu =3D=3D -1:
	This measures the calling process/thread on any CPU.

So it should work just fine, even when a thread is not pinned to a =
particular physical core.

[1]: https://man7.org/linux/man-pages/man2/perf_event_open.2.html