[dpdk-dev] [RFC] DPDK Trace support

Bruce Richardson bruce.richardson at intel.com
Mon Jan 13 17:12:59 CET 2020


On Mon, Jan 13, 2020 at 08:43:01PM +0530, Jerin Jacob wrote:
> 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.
> 
That seems impressively low, which is great news!

/Bruce


More information about the dev mailing list