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

[David Marchand]

On Thu, Apr 9, 2020 at 8:27 PM Jerin Jacob <jerinjacobk at gmail.com> wrote:
> > The global level is just disabling some logs even if it is enabled
> > in the logtype level.
> > It only makes usage complicate.
> > We should consider only logtype levels.
>
> OK.  Do we care about the following use case?
> # Trace only specific types of events(example, DEBUG or CRITICAL)?

The event types can be encoded in the tracepoint names if we want to
organise trace points with types (maybe as a suffix).

>
> IF NOT,
>
> There is no need for,
> # rte_trace_global_* API
> # No need to introduce trace type(ie DEBUG or CRITICAL) i.e remove
> rte_trace_level_set() API etc
>
>
> # In summary:
> ~~~~~~~~~~~~~
> # In the existing code:
> The trace will be emitted when
>  a) When the trace is enabled
>  AND
> b) trace level than the global level.
>
> # in new suggestion
> The trace will be emitted when
>  a) When it is enabled
>
> And the EAL argument will be --trace=regex/globbing, This EAL argument
> will call rte_trace_regexp() and enable the selected tracepoints.
>
> The downside will be it will not be similar to log API. I am fine with
> either way.

The level notion in the traces api is artificial.
I prefer a simple api where tracepoints state is controlled via a
single criteria: with the new suggestion that would be names.
So +1.


Afaiu, for logs, if we wanted to make use of the trace api, the level
notion can be done in the rte_log layer.


-- 
David Marchand