[dpdk-dev] [RFC] DPDK Trace support

[Jerin Jacob]

On Mon, Jan 13, 2020 at 8:28 PM Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> On Mon, Jan 13, 2020 at 08:16:07PM +0530, Jerin Jacob wrote:
> > On Mon, Jan 13, 2020 at 6:36 PM Bruce Richardson
> > <bruce.richardson at intel.com> wrote:
> > >
> > >
> > > > So, Probably it good to have native CTF emitter in DPDK and reuse all
> > > > open-source trace viewer(babeltrace and  TraceCompass) and format(CTF) infrastructure.
> > > > I think, it would be best of both world.
> > > >
> > > > Any thoughts on this subject? Based on the community feedback, I can work on the patch for v20.05.
> > >
> > > Forgive my ignorance of LTTng, but is there the concept of
> > > enabling/disabling the trace points? If so, the overhead you refer to, that
> > > is presumably with the trace enabled?
> >
> > Yes this is when trace is enabled. If the trace is disabled then it
> > will be the only a handful of cycles.
> >
> Two follow-on questions:
> 1. Is the trace enable/disable dynamic at runtime?

Yes. See the requirement section.

> 2. Have you investigated how low the "handful of cycles" actually is?

Yes. it is around 1 to 3 cycles based on the arch. it boils down to
mostly a branch hit/miss on a memory location
embedded in a C macro.

> While I think it is important to get the cost of tracing right down to make
> it useful, the cost of tracing when it is not being used is even more
> critical IMHO.

Yes.

>
> /Bruce