On Fri, Jan 13, 2023 at 09:09:21AM -0800, Tyler Retzlaff wrote: > On Fri, Jan 13, 2023 at 10:06:44AM +0530, Jerin Jacob wrote: > > 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. > > is the name what is really valuable here because it will only appear in > traces for linux with a new enough glibc, i.e. freebsd and windows it > will always be empty. > > we could just provide the thread id and that is available on all > platforms, i'd like to see consistency for all platforms if possible > here but i'm not pushing too hard since we don't declare our tracing > output to be a compatibility surface. > > can we just provide the thread id?
as a compromise i have submitted a new version for the series that curtails the scope of the original rte_thread_getname and allowing it at this single callsite. going forward however i would suggest we do not allow further internal use. thanks!
