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 3BC78A0542; Fri, 2 Dec 2022 09:03:30 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D126540687; Fri, 2 Dec 2022 09:03:29 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id CEE7B400D6 for ; Fri, 2 Dec 2022 09:03:27 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: help with pthread_t deprecation / api changes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Dec 2022 09:03:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8753E@smartserver.smartshare.dk> In-Reply-To: <20221202011218.GA32193@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: help with pthread_t deprecation / api changes Thread-Index: AdkF6yL0Li1h4C3pRz6TCIoCHUtWpwAM/I8w References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20221202011218.GA32193@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , , , , , "Bruce Richardson" 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 +Bruce, FreeBSD EAL maintainer > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Friday, 2 December 2022 02.12 >=20 > On Wed, Nov 30, 2022 at 02:54:27PM -0800, Tyler Retzlaff wrote: > > hi folks, > > > > i'd like to continue work moving to our platform abstracted > rte_thread > > but ran into a hiccup. for some recent and not so recent apis it > appears > > they managed to slip in without ever being __experimental. > > > > as a function of the dpdk project api/abi policy this means we can't > > change or remove some of these functions without following the > > deprecation process. > > > > the apis that are causing me immediate difficulty are > > rte_thread_setname and rte_ctrl_thread_create. >=20 > after looking in more detail at our current implementations of these > functions i would like to backtrack a little and limit the scope of > discussion to rte_thread_setname and rte_thread_getname. >=20 > as eal functions they aren't doing a good job in abstracting the > environment for applications, meaning an application would have to = wrap > their use in platform conditional checks. 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? 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! >=20 > current status. >=20 > 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) >=20 > 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. >=20 > 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 >=20 > i would propose to provide a replacement with the name > rte_thread_set_name with more consistent behavior across the 3 > platforms. >=20 > * 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.