[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