Re: [dpdk-dev] [PATCH v3 00/33] DPDK Trace support

[Thomas Monjalon <thomas@monjalon.net>]

01/04/2020 16:12, David Marchand:
> On Wed, Apr 1, 2020 at 12:05 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
> > On Wed, Apr 1, 2020 at 1:49 PM David Marchand <david.marchand@redhat.com> wrote:
> > > - Regardless of the trace framework, the ALLOW_EXPERIMENTAL_API flag
> > > gates access to APIs so that external users are aware of their status.
> > > I have been considering setting this flag unconditionally for internal
> > > users in the top Makefile/meson for app/ lib/ and drivers/.
> > > I could look at this and prepare a patch about this, but this is not
> > > enough here.
> >
> > It makes sense to me. Let me know when you are planning to send that patch,
> > I will rebase this series on top of that.
> 
> Feel free to take over, thanks.
> 
> 
> >
> > If you don't have time then I can send the patch too.
> > I assume the patch content will be:
> > 1) Removing experimental API from app, lib, drivers, examples with
> > make and meson
> > 2) Have it enabled at the global level.
> 
> examples are a special case as they can be compiled out of the dpdk sources.
> This is why I excluded them of the list in my mail before.
> 
> 
> > > How about:
> > > * we introduce a global config switch that enables/disables the trace
> > > framework (off by default): the people who want to test it and help
> > > stabilize it will have to deal with the experimental flag for now,
> > > * in 20.11, the trace points are put into the stable ABI, and the
> > > option is removed,
> >
> > IMO, the better alternative  would be:
> >
> > Since the trace changes in the "inline" functions of the specific
> > library already
> > disabled under _compile time_ RTE_ENABLE_TRACE_DP flag and
> > it is using RTE_TRACE_POINT_DP() to define the trace unlike slow path
> > trace like RTE_TRACE_POINT().
> 
> Ah indeed.
> Note: RTE_ENABLE_TRACE_DP is not plugged with meson.
> 
> 
> > So I can improve RTE_TRACE_POINT_DP() to make absolute NOP if
> > ALLOW_EXPERIMENTAL_API not defined.
> >
> > On the upside,
> > The tracing code will be enabled by default(runtime it is disabled by
> > default anyway).
> > If some need to fastpath API tracing then  ALLOW_EXPERIMENTAL_API need
> > to enable.
> > So this won't break applications.
> 
> So either keep the RTE_ENABLE_TRACE_DP flag or use
> ALLOW_EXPERIMENTAL_API... no opinion.
> Thomas?

Anyway we need a compile-time option?
The option is just for compatibility?
Then ALLOW_EXPERIMENTAL_API looks to be the right option.