On Thu, Sep 19, 2024 at 9:38 PM Morten Brørup <m...@smartsharesystems.com> wrote: > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > Sent: Thursday, 19 September 2024 17.49 > > > > On Thu, Sep 19, 2024 at 9:05 PM Morten Brørup <m...@smartsharesystems.com> > > wrote: > > > > > > > Could you share data with a real-world application of the elf size? > > > > 1)Without any change > > > > > > Size of the statically linked executable on the target file system: > > > 3,800,528 byte > > > > > > > 2)Only disabling via __rte_trace_point_emit_header_generic() .. aka > > > > below > > > > patch. > > > > > > 3,572,032 byte > > > > > > > 3)Full disable. > > > > > > 3,572,032 byte > > > > > > > > > > > I think, size command will spit out with different section's size. > > > > This data can be used to take decision and to know how much % it > > > > adding up? > > > > > > I.e. trace adds 228,496 byte = 6.4 % to the size of this specific > > executable. > > > > > > ~200 KB might not seem as much, but this is just omitting one module. > > > If other unused modules also add ~200 KB, it adds up. > > > > > > And I haven't done any significant additional memory footprint tuning. > > > > > > > > > > > > #define __rte_trace_point_emit_header_generic(t) \ > > > > > > void *mem; \ > > > > > > do { \ > > > > > > + if (RTE_TRACE == 0) \ > > > > > > + return \ > > > > > > Tested without the RTE_TRACE==0 check, simply: > > > void *mem; \ > > > do { \ > > > + return; \ > > > const uint64_t val = rte_atomic_load_explicit(t, > > rte_memory_order_acquire); \ > > > > > > > > > const uint64_t val = rte_atomic_load_explicit(t, > > > > > > rte_memory_order_acquire); \ > > > > > > if (likely(!(val & __RTE_TRACE_FIELD_ENABLE_MASK))) \ > > > > > > return; \ > > > > > > mem = __rte_trace_mem_get(val); \ > > > > > > if (unlikely(mem == NULL)) \ > > > > > > return; \ > > > > > > mem = __rte_trace_point_emit_ev_header(mem, val); \ > > > > > > } while (0) > > > > > > I don't understand why your method uses as little memory as mine... > > > > Compiler is start enough to understand those functions are NOP. > > Yes, I understand why the compiler understands that this code is NOP. > > But I don't understand why the tracepoints' values and names are not > registered by the unmodified RTE_TRACE_POINT_REGISTER().
My best _guess_ is __rte_trace_point_register()'s register_fn() execution comes as NOP. > > > > > > > > My method should also omit the trace points themselves, with their names > > > and > > numbers, and their initialization. > > > > > > I haven't looked deeper into it. > > > > > > If your method of omitting trace is as efficient as all my ifdefs, I also > > prefer your method. > > > Simpler is better. > > >
