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 9E588A0093; Fri, 9 Dec 2022 08:54:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F77640E0F; Fri, 9 Dec 2022 08:54:06 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 0FC3640E03 for ; Fri, 9 Dec 2022 08:54:04 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7B14A5C016C; Fri, 9 Dec 2022 02:54:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 09 Dec 2022 02:54:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1670572441; x= 1670658841; bh=51biGQQ2KpHVqJNSjumOIqfh+U8YGSHmFQpxcqpFEuo=; b=t lOA3FmZitXLdj/XNNCXNO0UC3h5jEv8YZ3f8lE3+Hb87fPwh4jlHZgrucuuZKLin Bs8ypFHjAX2Yv7+meIymF4FNWi7YHooPX0i9fsY9mkfkK/mbcUARXmpDRhtHxgbb viluvjz9YQWyefDnScooV6PBxOymjRqFsNeKvW78UX67/Yt+NAbsnoHLQKHQ29C0 AL8CER4oYIvFVdV44h0EaRbZ7UETvelUr+lf90N6Uo2a5e8XqgLx7oXoKwXg+MVR Hb37GyWJjW5/3z4oJOZwMU8y3iGCvJ2PNJTDSisAri/Qmq5401LBJbGrakybrZPH CBiD4VbJm0kSO0V63yc0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1670572441; x= 1670658841; bh=51biGQQ2KpHVqJNSjumOIqfh+U8YGSHmFQpxcqpFEuo=; b=F GGGbRuHla68myjd872ePx3V2/47LPeH0cF8nxBDgE6l+he7PMmSnF42yQQfkKD8U von/vpTkrDceH6PcnXVOFnjV+iK41CRi84cpLTlxr7bqeKyRqt6bUJ1NGsdRQie6 ALH9Z7lWH4twwL2dlR19y/1cGyxTMuw6UXf8/Relbi7C9xzN9u6F85YeN2c+TUEr UCrMZA++rSOmxzYcypUFQxplM29DwXLHY1u9sZqy9/FRUfWoaf7UZObYlrgOLoTz e4KQXQlVx49bywdGfSTgJYwC2yUsPJw3z453pm1ldOfYyqWXIbf9KFDE+lRMwbRY 65m5ISrYZoOzfhXcEYlZA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddugdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefhfejleeuvdevtddutdeutdevhfeijeethfffueejhfetuddu vedtkedtieekffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 9 Dec 2022 02:54:00 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= , Tyler Retzlaff Cc: dev@dpdk.org, david.marchand@redhat.com, stephen@networkplumber.org, Bruce Richardson Subject: Re: help with pthread_t deprecation / api changes Date: Fri, 09 Dec 2022 08:53:57 +0100 Message-ID: <2146119.C4sosBPzcN@thomas> In-Reply-To: <20221202195750.GA28809@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D8753E@smartserver.smartshare.dk> <20221202195750.GA28809@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 02/12/2022 20:57, Tyler Retzlaff: > On Fri, Dec 02, 2022 at 09:03:25AM +0100, Morten Br=F8rup wrote: > > +Bruce, FreeBSD EAL maintainer > >=20 > >=20 > > > > This is one of the consequences of a bloated EAL. > >=20 > > How is an application supposed to run on top of an EAL that isn't fully= implemented by the underlying environments? >=20 > 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. >=20 > unfortunately i'm dealing with things that pre-date that enlightenment. >=20 > > 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 eas= y to throw in new features, which really belong in separate libraries! > > > >=20 > > >=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. > >=20 > > My initial thought was that it should be provided for symmetry reasons. > > However, thinking about it, it is probably only used for debugging, tra= ce, and similar. It is probably not used in any meaningful way by applicati= ons. So I won't oppose to removing it. > >=20 > > Alternatively: > > If some execution environment doesn't support thread names, it could re= turn 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 > i think this raises a good question. is the purpose of setting a thread n= ame > 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? 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? > 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. >=20 > 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. In rte_ctrl_thread_create() the name is provided and limited to 16. > 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. >=20 > >=20 > > >=20 > > > rte_thread_setname > > > * freebsd, implemented, imposes no limit on name length, suppresses > > > errors > > > * linux, implementation conditional on __GLIBC_PREREQ(2, 12), impos= es > > > 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 witho= ut > > > error. > >=20 > > The function should not silently modify the provided data (i.e. truncat= e 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. >=20 > 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. >=20 > 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. >=20 > others feel free to chime in. >=20 > thanks! >=20