[PATCH v16 1/4] lib: add generic support for reading PMU events

Stephen Hemminger stephen at networkplumber.org
Wed Dec 4 01:55:28 CET 2024


On Wed, 4 Dec 2024 00:49:58 +0100
Morten Brørup <mb at smartsharesystems.com> wrote:

> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Tuesday, 3 December 2024 22.39
> > 
> > On Mon, 18 Nov 2024 08:37:03 +0100
> > Tomasz Duszynski <tduszynski at 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.


More information about the dev mailing list