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 B3A2CA0540; Fri, 2 Dec 2022 02:12:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A5F540689; Fri, 2 Dec 2022 02:12:21 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 54F9940687 for ; Fri, 2 Dec 2022 02:12:19 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 6204620B83C2; Thu, 1 Dec 2022 17:12:18 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6204620B83C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1669943538; bh=K3zMfm52cNX6U0UKWw08uwM0pou1GBVvjZHQhlPnhPU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=rsqgk0Houfjatd3JZjAxGjm/z1kG49fWNYVQYIJqL7Yp6z+gYp9m2t4P6UfJvLpIq vUSacCISA9qYNvkLJUuQrd7S4V4CQnI0X451iqesk4nTrH1Ws8tADT5YUENNp7ZQEm PCN1VYp2snD9KuhJ3NvxLt+WyQFSx2TVOpmXIC9E= Date: Thu, 1 Dec 2022 17:12:18 -0800 From: Tyler Retzlaff To: dev@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com, mb@smartsharesystems.com, stephen@networkplumber.org Subject: Re: help with pthread_t deprecation / api changes Message-ID: <20221202011218.GA32193@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 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. 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. 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. 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. 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. your feedback would be appreciated. thanks > i think the least painful path forward to deprecating and removing these > apis is probably just to introduce the replacements with new names. > > 1. introduce functions with the following names marked as > __experimental. > > rte_control_thread_create(rte_thread_t *, ...) > rte_thread_set_name(rte_thread_t, ...) > rte_thread_get_name(rte_thread_t, ...) > > along with the new functions, new unit tests will be included. > > 2. update dpdk internal implementation to use the new functions. > > 3. immediately remove the following functions from the public headers > and issue an api deprecation notice for the functions not marked > experimental. > > rte_ctrl_thread_create(pthread_t *, ...) > rte_thread_setname(pthread_t *, ...) > > 4. when the new functions have their __experimental marking removed > issue an abi deprecation notice for the functions from (2). > > i'm open to feedback/suggestions of a better approach if anyone has one > to offer. > > thanks!