> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Tuesday, 3 December 2024 22.39 > > On Mon, 18 Nov 2024 08:37:03 +0100 > Tomasz Duszynski <tduszyn...@marvell.com> wrote: > > > +Performance counter based profiling > > +----------------------------------- > > + > > +Majority of architectures support some performance monitoring unit > (PMU). > > +Such unit provides programmable counters that monitor specific > events. > > + > > +Different tools gather that information, like for example perf. > > +However, in some scenarios when CPU cores are isolated and run > > +dedicated tasks interrupting those tasks with perf may be > undesirable. > > The data should be folded into telemetry rather than introducing yet > another > DPDK API for applications to deal with.
I strongly prefer the dedicated high-performance PMU API rather than using telemetry for this. Please keep the PMU API. I expect to call the PMU API in our (proprietary) run-time profiling library, where reading PMU counters should be as lean as calling rte_rdtsc(). I sure don't want any superfluous overhead when profiling with a very high sampling rate. For reference, many other libraries have dedicated APIs for reading the statistics structures of those libraries. A wrapper around the PMU API can be added for Telemetry. IMO, the Telemetry library should be made optional, like the Trace library recently was. For embedded systems, they are not only bloat, but potentially helpful for hackers trying to break in. And Security is one of the DPDK Governing Board's focus areas.
