[dpdk-dev] [RFC] DPDK Trace support

Jerin Jacob jerinjacobk at gmail.com
Fri Jan 17 11:54:55 CET 2020


On Fri, Jan 17, 2020 at 4:00 PM Mattias Rönnblom
<mattias.ronnblom at ericsson.com> wrote:
>

> > LTTng kernel tracing only needs kmod support.
> > For the userspace tracing at minium following libraries are required.
> >
> > a) LTTng-UST
> > b) LTTng-tools
> > c) liburcu
> > d) libpopt-dev
>
> This "DPDK CTF trace emitter" would make DPDK interoperate with, but
> without any build-time dependencies to, LTTng. Correct?

Yes. Native CTF trace emitter without LTTng dependency.

>
> Do you have any idea of what the performance benefits one would receive
> from having something DPDK native, compared to just depending on LTTng UST?

I calibrated LTTng cost and pushed the test code to github[1].

I just started working on the DPDK native CTF emitter.
I am sure it will be less than LTTng as we can leverage hugepage, exploit
dpdk worker thread usage to avoid atomics and use per core variables,
avoid a lot function pointers in fast-path etc
I can share the exact overhead after the PoC.
I think, based on the performance we can decide one or another?

[1]
-------------------------- 8<----------------------------------
https://github.com/jerinjacobk/lttng-overhead
https://github.com/jerinjacobk/lttng-overhead/blob/master/README

On high-end x86, it comes around 236 cycles/~100ns @ 2.4GHz (See the
last line in the log(ZERO_ARG))
On arm64, it varies from 312 cycles to 1100 cycles(based on the class of CPU).
In short, Based on the "IPC capabilities", The cost would be around
100ns to 400ns
for single void trace(a trace without any argument)
-------------------------- 8<----------------------------------


>
> Would this work also include moving over the DPDK trace macros to using
> this new CTF trace emitter? If so, we would retain the current
> printf()-style pattern, or move to a more LTTng-native like approach,
> with trace event type declarations and binary-format trace events?

Yes. I am planning to add tracepoints across the DPDK source code.
The Fastpath stuff should be under conditional compilation.
My view is to keep the printf() pattern as is. Probably we can decide
the exact treatment later.


More information about the dev mailing list