Hi Thomas, >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?
I initially started PMU as something tightly coupled with EAL, but after feedback from other developers I decided to decouple it completely [1]. The Technical Board also discussed this and supported the idea of having PMU as a separate library [2]. The main goal is to keep EAL lean and focused only on core essentials, making the PMU code easier to manage separately. This separation aligns nicely with the broader effort to simplify EAL by moving optional features out. [1] https://lore.kernel.org/dpdk-dev/20230111210547.ga2...@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/ [2] https://mails.dpdk.org/archives/dev/2023-January/260035.html#:~:text=PMU%20Library%20,principle%20for%20inclusion%20in%20DPDK
