> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, 4 December 2024 01.55 > > 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?
I don't know enough about perf to provide a qualified answer to this. Our data plane profiling library has very high resolution. Think of it gathering information about every single run of each pipeline stage, thus also providing detailed information about outliers. > 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.
