From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F3E06A0093; Sat, 10 Dec 2022 00:49:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8AFF540A84; Sat, 10 Dec 2022 00:49:48 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id EB24D40042 for ; Sat, 10 Dec 2022 00:49:47 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 2CAFB20B6C40; Fri, 9 Dec 2022 15:49:47 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2CAFB20B6C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670629787; bh=wtFR2IkqHzUbvtPJ4Vw2lcmNrXPbv/Bg0Fz/KsYDUGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iGZqZauwB2KjIn9UsYbzbpC63UjG04B2dYNsL3Zv2prLHhzDMIKSvMkANlt4LySsr 9Yz6iSMRyi4bmzmP1Xn+vj93Z+KL3fze1HtxAAbMkcjoU5/sPdPqdPB7x1y/temNSe a0ISY+xqUbc8JzkvjXCzqnnyLQVwWY495ZNtDd0c= Date: Fri, 9 Dec 2022 15:49:47 -0800 From: Tyler Retzlaff To: Thomas Monjalon Cc: Stephen Hemminger , dev@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= , david.marchand@redhat.com, Bruce Richardson Subject: Re: help with pthread_t deprecation / api changes Message-ID: <20221209234947.GA26599@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20221209084814.3b1479d5@hermes.local> <20221209200613.GB19263@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <6848416.18pcnM708K@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6848416.18pcnM708K@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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 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. 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. thanks.