[PATCH v2 1/4] eal: add thread set name API operating on rte thread

[Tyler Retzlaff]

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.marchand at redhat.com> wrote:
> >
> > On Wed, Dec 14, 2022 at 5:47 PM Tyler Retzlaff
> > <roretzla at 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?

> 
> >
> >
> > --
> > David Marchand
> >