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 0AFE6A0540; Fri, 2 Dec 2022 20:57:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A48C940687; Fri, 2 Dec 2022 20:57:53 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id ABF1E400D6 for ; Fri, 2 Dec 2022 20:57:51 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id B375F20B83C2; Fri, 2 Dec 2022 11:57:50 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B375F20B83C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670011070; bh=836Ym91pGO+VxBnlg78bl0wNDLs1NlVKMxoee+WbgLU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Dw+YQ8fkkyJoyj8abrN+MucpDNEsJSuoMGFqFt7TBsSJHFBdEYZz+0Nj76c3zCylo LKMumcntxYNnPsgNyC41iTX5e5L4QxXahvAvVn6bht9tYYwcm8/V4f3qnDGAtdrMuK FP3+fl/hijIwtlrngrduMiRrPulrQvaN2/XRlfmI= Date: Fri, 2 Dec 2022 11:57:50 -0800 From: Tyler Retzlaff To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com, stephen@networkplumber.org, Bruce Richardson Subject: Re: help with pthread_t deprecation / api changes Message-ID: <20221202195750.GA28809@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20221202011218.GA32193@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D8753E@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8753E@smartserver.smartshare.dk> 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 02, 2022 at 09:03:25AM +0100, Morten Brørup wrote: > +Bruce, FreeBSD EAL maintainer > > > > This is one of the consequences of a bloated EAL. > > How is an application supposed to run on top of an EAL that isn't fully implemented by the underlying environments? yep, i'm aware of your other thread and i am in complete agreement with you. i think as a rule of thumb if we can't reasonably provide an abstraction that behaves consistently then it isn't something that should be in the eal at all. unfortunately i'm dealing with things that pre-date that enlightenment. > I have complained about this before, but am not afraid to repeat it: > I wish the EAL wasn't treated as some catch-all library where it is easy to throw in new features, which really belong in separate libraries! > > > > > > current status. > > > > rte_thread_getname > > * freebsd, no implementation and it appears no possible support > > * linux, implementation conditional on __GLIBC_PREREQ(2, 12) > > * windows, can be implemented but isn't, noop success > > * fortunately is marked __rte_experimental > > * called in 1 place only from eal (logging) > > > > i would propose to present a consistent abstraction the best thing to > > do > > here is just remove rte_thread_getname. providing a version that > > requires an application to do conditional dances / compilation based on > > platform gains nothing. > > My initial thought was that it should be provided for symmetry reasons. > However, thinking about it, it is probably only used for debugging, trace, and similar. It is probably not used in any meaningful way by applications. So I won't oppose to removing it. > > Alternatively: > 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? right now it is trying to be both and the both is trying to build on unaligned platform facilities. one thing we could do here is decouple the two. if the purpose was to allow a name to be get,set by the application it could just be stored with dpdk lcore state and does not need to be fed into pthread_{set,get}name_np. it can continue to be consumed by logging/the application. extending that we could say there is a 'side-effect' that internally if your platform does support pthread_{set,get}name_np then it will be called as well, but if it fails we don't care. > > > > > rte_thread_setname > > * freebsd, implemented, imposes no limit on name length, suppresses > > errors > > * linux, implementation conditional on __GLIBC_PREREQ(2, 12), imposes > > limit of 16 (including terminating NUL) on name length, may return > > an > > error > > * windows, can be implemented, no explicit limit on name length, may > > return errors > > * unfortunately not marked __rte_experimental > > > > i would propose to provide a replacement with the name > > rte_thread_set_name with more consistent behavior across the 3 > > platforms. > > > > * returns errors for platforms that return errors, but the caller > > is free to ignore them. > > * explicit limit of 16 (including terminating NUL) on name length, > > names that are provided that exceed the limit are truncated without > > error. > > The function should not silently modify the provided data (i.e. truncate the name). I would prefer doing both: Return ERANGE (like pthread_setname_np()), but use the truncated name anyway. Then the application can choose to ignore or deal with the return code. i agree with this, but the current linux implementation is already doing it, i'd be inclined to say if we have a limit we should just fail the set. i'm beginning to think that complete removal of set,get thread name is what we want here and if we need names for things like logging we provide a facility not tied to the underlying platform threading. others feel free to chime in. thanks!