> > > > > > They are setting levels with regex or globbing. > > > --log-level supports 3 syntaxes today: > > > - int (global level) > > > - globbing:int > > > - regex,int > > > > Here is my understanding. > > > > IMO, Actual Syntax is > > - int (global level) > > - globbing: int (global level) > > - regex: int (global level) > > The level apply to the logs matching the pattern (globbing or regex) > so I don't understand why you call it "global".
What I meant is, if there is no global, what is the point of changing the trace level with EAL command-line argument with globbing and regex. > > > i.e > > > > 1) Each log/trace has a "level" > > 2) There is a global level. See [1] > > 3) The trace will be emitted when > > a) When it is enabled(not applicable for log as it is always enabled) > > AND > > b) it is less than the global level. > > When it is less than both global and logtype level. > See rte_log_can_log(). OK. > > 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)? 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. @Mattias Rönnblom, Do you have any thoughts as you spend some time reviewing the public API. Thoughts in general?
