> From: Tomasz Duszynski [mailto:tduszyn...@marvell.com] > Sent: Monday, 16 June 2025 11.49 > > >16/06/2025 08:53, Tomasz Duszynski: > >> @@ -86,6 +86,7 @@ always_enable = [ > >> 'ring', > >> 'stack', > >> 'telemetry', > >> + 'pmu', > >> ] > > > >This list is alphabetically sorted. > > Right, missed that. > > > > >What is the justification for always enabling PMU lib? > >Is it a good idea to always enable an experimental library? > > Well, since on Linux eal depends on pmu, disabling pmu ends up disabling > eal, which breaks minimal build. > > As for the second question - no. I think ideally lib should remain > optional. However, since trace is part of eal, that indirectly forces > pmu to be built.
Trace is optional, controlled by RTE_TRACE in /config/rte_config.h. > > Alternatively, I guess we could make the library explicitly optional by > extra meson option. But given that there are already options for > controlling libraries that approach is not perfect either. PMU should depend on EAL, not the other way around. Please refer to this fix, where pmu.c is updated to call rte_mem_page_size(), which includes error handling, instead of directly calling sysconf(_SC_PAGE_SIZE) without handling errors from it: https://patchwork.dpdk.org/project/dpdk/patch/20250612140657.313785-1...@smartsharesystems.com/ If there are cross dependency issues due to integration between PMU and Trace, adding the PMU related trace directly in the Trace library is a much better solution than making EAL depend on PMU. Also, I agree with Thomas that PMU should not be considered a mandatory core library (always_enable).
