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

Tyler Retzlaff roretzla at linux.microsoft.com
Fri Jan 13 19:56:08 CET 2023


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.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?

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!


More information about the dev mailing list