On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjac...@gmail.com> wrote: > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.march...@redhat.com> > wrote: > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjac...@gmail.com> wrote: > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.march...@redhat.com> > > > wrote: > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > this largely grows the number of constructors been called. > > > I had concerns about the boot time of the application and/or loading > > > the shared library, that the reason why spitting > > > as two so that constructor registers a burst of traces like rte_log. > > > > I am a bit skeptical. > > In terms of cycles and looking at __rte_trace_point_register() (which > > calls malloc), the cost of calling multiple constructors instead of > > one is negligible. > > We will have a lot tracepoints latter, each one translates to the > constructor may not be a good > improvement. The scope is limited only to register function so IMO it > is okay to have split > just like rte_log. I don't see any reason why it has to be a different > than rte_log.
What is similar to rte_log? There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of dynamic logtypes. > > One of the thought process is, we probably remove the constructor > scheme to all other with DPDK > and replace it with a more register scheme. In such a case, we can > skip calling the constructor all tother > when trace is disabled. Sorry, but I have a hard time understanding your point. Are you talking about application boot time? -- David Marchand
