On Mon, Jan 13, 2020 at 8:28 PM Bruce Richardson <bruce.richard...@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.richard...@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
