DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Tyler Retzlaff <roretzla@linux.microsoft.com>
Cc: "Stephen Hemminger" <stephen@networkplumber.org>,
	dev@dpdk.org, "Morten Brørup" <mb@smartsharesystems.com>,
	david.marchand@redhat.com,
	"Bruce Richardson" <bruce.richardson@intel.com>
Subject: Re: help with pthread_t deprecation / api changes
Date: Sun, 11 Dec 2022 08:50:48 +0100	[thread overview]
Message-ID: <14786965.JCcGWNJJiE@thomas> (raw)
In-Reply-To: <20221209234947.GA26599@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

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 <thomas@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 <thomas@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.



  reply	other threads:[~2022-12-11  7:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 22:54 Tyler Retzlaff
2022-12-02  1:12 ` Tyler Retzlaff
2022-12-02  8:03   ` Morten Brørup
2022-12-02 19:57     ` Tyler Retzlaff
2022-12-09  7:53       ` Thomas Monjalon
2022-12-09 16:48         ` Stephen Hemminger
2022-12-09 20:06           ` Tyler Retzlaff
2022-12-09 21:13             ` Thomas Monjalon
2022-12-09 23:49               ` Tyler Retzlaff
2022-12-11  7:50                 ` Thomas Monjalon [this message]
2022-12-12 17:45                   ` Tyler Retzlaff
2022-12-13  8:32                     ` Thomas Monjalon
2022-12-13 17:38                       ` Tyler Retzlaff
2022-12-13 19:34                         ` Thomas Monjalon
2022-12-13 20:39                           ` Morten Brørup
2022-12-14  0:16                             ` Tyler Retzlaff
2022-12-09 21:14           ` Thomas Monjalon
2022-12-09 22:38             ` Stephen Hemminger
2022-12-09 23:55               ` Tyler Retzlaff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14786965.JCcGWNJJiE@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).