On Fri, Apr 10, 2020 at 8:42 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 10/04/2020 15:29, Jerin Jacob: > > 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: > > > > # 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. > > I miss the plan to rework logs on top of trace. > How could it be done?
# I think, David suggestion is to add "level" as a string in the trace name. Say "debug.lib.eal.*" # I am thinking, If we don't like above, a) Add following EAL private APIs to get and set "level" as opaque object when _needed_ from trace. 1) int eal_trace_opaque_set(rte_trace_t trace, uint8_t opaque); 2) uint8_t eal_trace_opaque_get(rte_trace_t trace); The above private API would be enough to implement. > >
