[PATCH v17 0/4] add support for self monitoring
Morten Brørup
mb at smartsharesystems.com
Tue Jun 3 16:17:38 CEST 2025
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Tuesday, 3 June 2025 15.28
>
> Hello,
>
> 17/01/2025 10:00, Tomasz Duszynski:
> > lib/pmu/meson.build | 22 +
> > lib/pmu/pmu_arm64.c | 94 ++++
> > lib/pmu/pmu_private.h | 32 ++
> > lib/pmu/rte_pmu.c | 537
> +++++++++++++++++++++++
> > lib/pmu/rte_pmu.h | 251 +++++++++++
> > lib/pmu/rte_pmu_pmc_arm64.h | 30 ++
> > lib/pmu/rte_pmu_pmc_x86_64.h | 24 +
>
> Reading it again, I wonder why it is a separate library.
> In general we give access to the hardware in EAL.
> Why not having PMU in EAL?
>
IMO, the EAL should be a thin shim layer, providing abstractions to only the "must have" parts of any underlying hardware and O/S running the DPDK application, not auxiliary hardware or O/S features. The EAL is already bloated with stuff that is not absolutely required to run simple DPDK applications.
As an advocate for a slimmer EAL, having PMU as a separate library makes sense to me.
Not all hardware access is provided through the EAL.
E.g., access to hardware power management controls is provided through the Power library/driver combo.
The PMU feature could be considered a type of "library/driver" combo, like the Power library/driver combo; but that might come with unnecessary complexity and performance overhead from additional abstractions and indirect function calling, so I don't like this alternative.
-Morten
More information about the dev
mailing list