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.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. > That seems impressively low, which is great news!
/Bruce
