On Wed, Jan 11, 2023 at 9:39 PM David Marchand <david.march...@redhat.com> wrote: > > On Wed, Dec 14, 2022 at 5:47 PM Tyler Retzlaff > <roret...@linux.microsoft.com> wrote: > > diff --git a/lib/eal/common/eal_common_trace.c > > b/lib/eal/common/eal_common_trace.c > > index 5caaac8..89522dc 100644 > > --- a/lib/eal/common/eal_common_trace.c > > +++ b/lib/eal/common/eal_common_trace.c > > @@ -356,8 +356,6 @@ rte_trace_mode rte_trace_mode_get(void) > > /* Store the thread name */ > > char *name = header->stream_header.thread_name; > > memset(name, 0, __RTE_TRACE_EMIT_STRING_LEN_MAX); > > - rte_thread_getname(pthread_self(), name, > > - __RTE_TRACE_EMIT_STRING_LEN_MAX); > > > > trace->lcore_meta[count].mem = header; > > trace->nb_trace_mem_list++; > > Note, this belongs to patch 2. > > I understand we can drop the thread name retrieval helper from public > API, but at least for the trace framework it added some info in the > traces. > Jerin, Sunil, what do you think? Should we keep this helper internally?
Good catch @David Marchand. Yes, we should be it as internal helper API use it here. For trace, It will be difficult to make sense without thread name. > > > -- > David Marchand >
