On Fri, Jan 17, 2020 at 5:41 AM Jerin Jacob <jerinjac...@gmail.com> wrote:
>
> > > > >
> > > > > 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!
>
> Does anyone have an objection to have
> 1) Use CTF as trace format to reuse the opensource tracing tools and
> compatibility wth LTTng
> https://diamon.org/ctf/
> 2) Have native DPDK CTF trace emitter for better performance for DPDK
> fast path tracing and Non-Linux support.
>
> I would like to avoid the situation where once code gets completed and
> then starts our basic discussion
> on the design decisions.
>
> If someone needs more time to think through or any clarification is
> required then please discuss.

I did not find the time to look at this.
Some quick questions:
- is LTTng coming with out-of-tree kmod? making it hard to support in
distributions?
- I have been playing with perf those days to track live processes and
gathering informations/stats at key point of a dpdk app without adding
anything in the binary. What does LTTng provide that scripting around
perf would not solve?


-- 
David Marchand

Reply via email to