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. 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. > > > -- > David Marchand >
