On Wed, Apr 01, 2020 at 09:55:20PM +0530, Jerin Jacob wrote: > On Wed, Apr 1, 2020 at 7:42 PM David Marchand <david.march...@redhat.com> > wrote: > > > > On Wed, Apr 1, 2020 at 12:05 PM Jerin Jacob <jerinjac...@gmail.com> wrote: > > > On Wed, Apr 1, 2020 at 1:49 PM David Marchand <david.march...@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. > > OK. > > > > > > > > > > > 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. > > There are a lot of examples already that have ALLOW_EXPERIMENTAL_API. > What is the issue in enabling ALLOW_EXPERIMENTAL_API in the in tree > example application? > > > > > > > > > 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. > > If you see the " eal: define the public API for trace support" patch, > I have updated rte_config.h for meson likewise for other configuration > such log for DP. > Would you like to have a meson option? and update in meson_options.txt. > > I don't have a strong opinion on either way? Bruce ,any thoughts? > Since it's likely that developers will be wanting to switch this option on and off, I think an explicit option rather than hard-coded constant should be the way to go.
However, an alternative might be to add in the DP tracing for debug builds but not for others. This would save a build option, but may be more restrictive, since debug builds can also be optimized ones. /Bruce
