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 99C55A034C; Mon, 12 Dec 2022 18:45:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8191740687; Mon, 12 Dec 2022 18:45:46 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 9E8BB40684 for ; Mon, 12 Dec 2022 18:45:45 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id E82A320B717A; Mon, 12 Dec 2022 09:45:44 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E82A320B717A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670867144; bh=bH180mYM+5EE1fqSkPKFnW6/0Ff0NPjqdRLFMt/J2fA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=H8YlZ4leEGsnQ3KLI9wd8f9WIR0A8mHm418t4lOIBLr3br6q5L0JRMl9i6lGpzw8S HXcTF5Gpga1C3Tty4bqAAs9bX3du8c5wcaPLLjuFVhqJLf6FJvewfbnFTc/D5VvCBA 8dJgdpt6XdX5cXmYOFybsKnc4jA6bgYIZ7x2k2HI= Date: Mon, 12 Dec 2022 09:45:44 -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: <20221212174544.GA27595@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <6848416.18pcnM708K@thomas> <20221209234947.GA26599@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <14786965.JCcGWNJJiE@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14786965.JCcGWNJJiE@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 Sun, Dec 11, 2022 at 08:50:48AM +0100, Thomas Monjalon wrote: > 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 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. > > 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. > sorry i thought you had been looking at our implementation, let me summarize. here are the differences between the underlying platform capabilities that prohibit both get and set. it's not a matter of just providing missing implementation for a specific platform. set thread name: freebsd - set reports no failure, but may silently fail - uncertain what name length limit is linux - set not available in older glibc - current rte wrapper silently truncates name length windows - set always available - uncertain what name length limit is get thread name: freebsd - not available at all linux - get not available in older glibc - get can fail windows - get always available - get can fail keep in mind the purpose of an abstraction is that the application *does not* have to do conditional evaluation on a per-platform basis around call sites. once you start putting #ifdef RTE_EXEC_ENV_XXX into code you failed and i presume we want none of the use of eal to be adorned with that. at first glance you might think oh, well if get isn't supported then just return some default string or an empty string but even that is a violation of the abstraction that leaks implementation detail. i.e. assuming success set() success get(set()) should also succeed without conditional compilation of the code. the common abstraction that can be reasonably provided explicitly operating a thread is something like. * for set you can provide a watered down version that doesn't report failure and silently truncates and ignores errors within the implementation. if it works it works if it doesn't you just don't know i.e. best effort. * for get it cannot be provided consistently, the platforms simply aren't providing what is needed. for background one of the request to expose the native platform thread id was to access the best effort behavior for the thread associated with an lcore. discussion on list highlighted the constraint that this should be done without exposing platform specific detail via the eal api. http://mails.dpdk.org/archives/dev/2022-October/253411.html as mentioned in a previous mail i provided a series that accomplishes this as a side effect of an api that can be consistently provided when available on the platform, it has 2 benefits. * it does not expose the platform-specific native thread handle. * for lcores it keeps the name in the application memory so it is available in crash/coredumps. so we have 2 options. 1. a watered down set (no get) that is fire and forget and reports no failure and maybe it works, maybe it doesn't depending on your platform. 2. the lcore set / get which is basically (1) for the threads associated with lcores but provides some additional features that are supportable in the api surface. (set/get, stored in application namespace). great discussion, please let me know your thoughts and what direction we'd like to go i'll adjust patches as appropriate. thanks.