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
