On Wed, Jan 11, 2023 at 05:09:25PM +0100, David Marchand 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.
agreed, not sure how i fumbled that. since there has been no reply about retaining rte_thread_getname as an internal api i'll just move this change 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? > > > -- > David Marchand
