> From: Thomas Monjalon [mailto:tho...@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
