On Fri, Apr 10, 2020 at 6:45 PM David Marchand <david.march...@redhat.com> wrote: > > 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.
I thought it may be helpful to replace log and I decided to pick the level in the trace. Looks like the consensus is to remove "level" from Trace. OK. I will rework the Trace API to remove the "level" and rte_trace_global_* API from Trace library. Let me know If you have any other top-level architecture comments if any. I will send v5 with new changes. > > > Afaiu, for logs, if we wanted to make use of the trace api, the level > notion can be done in the rte_log layer. That works too. > > > -- > David Marchand >