10/12/2022 00:49, Tyler Retzlaff:
> On Fri, Dec 09, 2022 at 10:13:44PM +0100, Thomas Monjalon wrote:
> > 09/12/2022 21:06, Tyler Retzlaff:
> > > On Fri, Dec 09, 2022 at 08:48:14AM -0800, Stephen Hemminger wrote:
> > > > On Fri, 09 Dec 2022 08:53:57 +0100
> > > > Thomas Monjalon <tho...@monjalon.net> wrote:
> > > >
> > > > > > > If some execution environment doesn't support thread names, it
> > > > > > > could return a string that makes it possible for a human to
> > > > > > > identify the thread, e.g. the tread id. Again, this is assuming
> > > > > > > that it is only used for debugging, trace, and similar.
> > > > > >
> > > > > > i think this raises a good question. is the purpose of setting a
> > > > > > thread name
> > > > > > meant to be something we can use from the application or is it
> > > > > > something that
> > > > > > is for debugging diagnostics and may be a best effort?
> > > > >
> > >
> > > > Thomas Monjalon <tho...@monjalon.net> wrote:
> > >
> > > > I think yes it is only for debugging.
> > > > So best effort looks to be a good approach.
> > > > I'm not sure you need to replace the functions.
> > > > Can you just complete the implementations?
> > >
> > > the patch series put forward allows a set / get name per-lcore, where
> > > you get implicit (but not exposed via the eal api) call to underlying
> > > platform thread setname.
> >
> > I don't understand how lcore ID and thread ID are connected.
> > You can run multiple control threads on a single lcore.
> >
>
> correct.
>
> the new public api allows the set of a name on an lcore only. as a
> side-effect if the platform supports it the name is also set on the
> thread_id associated with the lcore (from lcore_config[].thread_id).
>
> for control threads you just get the side-effect if the platform
> supports it, otherwise it is a noop.
What does it mean? which side effect? what must be supported?
> if we want set / get name at all this seemed the most usable balance
> between application consumption with debug use where available. if this
> isn't acceptable then i would suggest we simply remove both
> rte_thread_{get,set}name because as a debugging facility we cannot offer
> a consistent abstracted api which means it shouldn't be in the eal at
> all.
Why it cannot be consistent?
Please be more precise.
