[dpdk-dev] [PATCH v4 00/33] DPDK Trace support

[Jerin Jacob]

On Thu, Apr 9, 2020 at 7:30 PM Thomas Monjalon <thomas at monjalon.net> wrote:
>
> Hi,
>
> 03/04/2020 17:36, jerinj at marvell.com:
> > Features:
> > ~~~~~~~~~
> > - APIs and Features are similar to rte_log dynamic framework
> > API(expect log prints on stdout vs it dumps on trace file)
>
> A log can print to syslog as well.
>
> As discussed somewhere else, please do not introduce global level
> in rte_trace. I think it is useless. If we need to change the level
> of all trace types, we can just use a wildcard (globbing or regexp).


Currently, In the log library, when EAL command-line argument
specifies the "--log-level=val" it, will call
the  rte_log_global_level_set(val)

Is the suggestion to make rte_log_global_level_set() as an internal
EAL API or remove that feature?
If we remove, then I dont know, how we can map --log-level or
--trace-level EAL command-line argument.

>
> And about wording, "pattern" is too vague and should be replaced
> with "globbing".

Currently, we are using the word "shell pattern" in log and trace.
According to man 3 fnmatch, both being used.
I can send a patch for changing the "shell pattern" to  "glob" in
rte_log.h and update the trace if needed.
Let me know?. IMO, Both has to use same word.

>
>
> > - No specific limit on the events. A string-based event like rte_log
> > for pattern matching
>
> Would it be possible to replace rte_log with rte_trace?

Yes, I kept public API similar to log to have that use case in mind.

>
>
> > - Dynamic enable/disable support.
>
> How dynamic it is? Can we start/stop a trace after starting DPDK?

Yes, we have fine control enabling and disabling a specific or group of events.
See rte_trace_enable(), rte_trace_disable() and rte_trace_pattern()

> I think we need a control channel for this.
> I propose to introduce a general control channel in DPDK.

Yes. Once we have a general control channel in DPDK. We can hook
rte_trace_enable() and friends
in the message handler.

>
>
> > - Instructmention overhead is ~1 cycle. i.e cost of adding the code
>
> Nice
>
>
> > wth out using trace feature.
> > - Timestamp support for all the events using DPDK rte_rtdsc
>
> Could we use other timestamp sources, like the mbuf timestamp
> for Rx traces?

Trace will be running at the global wall clock. Rx specific tracepoint
can add mbuf->timestamp as FIELD in the future if needed.

>
>
> > - No dependency on another library. Clean room native implementation of
> >   CTF.
>
> No benefit of using an external CTF library maintained somewhere else?

See performance data comparison with LTTng in the cover letter.

We discussed this enough in the mailing list on RFC and decide to use
Faster trace support for Fastpath use case and avoid any external library to EAL
(We need tracepoints in the EAL too for tracing).

>
>
>