Re: [EXTERNAL] Re: [PATCH v4 1/3] perf: marvell: Add MPAM partid filtering to CN10K TAD PMU
Will Deacon <[email protected]> Fri, 31 Jul 2026 16:27:50 +0100
| Newsgroups | org.kernel.vger.linux-perf-users,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jun 26, 2026 at 09:57:44AM +0100, Ben Horgan wrote: > >> Where is the user expected to get the PARTID from? The MPAM driver > >> considers the PARTID as an internal only value. > >> … > >> Perhaps some helpers along the lines of: > >> int resctrl_mount_generation(void) > >> … > > Thank you for the detailed feedback — the concern you raise is valid, particularly when > > viewed from the perspective of resctrl-managed deployments. > > > > However, to clarify the intent of this patch: the exposure of partid in the TAD PMU is deliberately > > a low-level, hardware-facing interface, and is not intended to integrate with or mirror the > > abstractions provided by resctrl. It is mainly meant for platform bring-up and low-level > > performance/debug users, who already have explicit knowledge of the MPAM configuration, > > typically provisioned by firmware or other privileged software layers (e.g. EL3/EL2). > > In such environments, PARTIDs are known out-of-band, so the expectation is that the > > user supplying partid is already aware of the MPAM IDs programmed on the system. > > When this was proposed before, [1], there was feedback asking to > document how to get the PARTID. Yes, please can you update the documentation to cover this? I'm not necessarily asking for a programmatic way to do it, but even something like a reference to a document or a firmware table would be useful for people trying to use the driver to profile their workload. Otherwise, it's just an opaque id :/ There are also some comments from Sashiko to consider: https://sashiko.dev/#/patchset/[email protected]?part=1 Thanks, Will