On Wed, 4 Dec 2024 00:49:58 +0100 Morten Brørup <m...@smartsharesystems.com> wrote:
> > 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. > Can this data go right into perf? It is not clear why this is better than just using perf? The one use case I can think of is a cloud provider with lots and lots of embedded systems. But in that case they already have much more detailed and integrated tools, the DPDK stuff is not needed.
