On Thu, Apr 9, 2020 at 8:27 PM Jerin Jacob <jerinjac...@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
