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 525A4A034C; Wed, 21 Dec 2022 18:54:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EAB6840A7F; Wed, 21 Dec 2022 18:54:47 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 44D1C40A7A for ; Wed, 21 Dec 2022 18:54:46 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 7BE8C20C3380; Wed, 21 Dec 2022 09:54:45 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7BE8C20C3380 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1671645285; bh=RgSrWZ92PTLXmfPmv3sc3UkWRvwM9mrthgaqV/kYK+I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hwOq229CEw5uZCAHDbTVDbEUxLfwni12k1t3l3vq9bsn12byWnzIXfFE8oNA7W6Kt BTDhwEL/PfYLGvJqSFhL4ODUdy22do6BG7PAgwXT3MoJScroeWhWU/PxW+AbytDVMa nUtozgYLI4iwBKkWOlzfP4IF7ZpueRPLZSuu08/Q= Date: Wed, 21 Dec 2022 09:54:45 -0800 From: Tyler Retzlaff To: David Marchand Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, mattias.ronnblom@ericsson.com Subject: Re: [RFC] eal: per-thread constructors/destructors Message-ID: <20221221175445.GA20526@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <98CBD80474FA8B44BF855DF32C47DC35D875C4@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: 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, Dec 21, 2022 at 05:12:54PM +0100, David Marchand wrote: > On Sun, Dec 18, 2022 at 11:01 AM Morten Brørup wrote: > > > > This RFC introduces per-thread constructors/destructors: > > * Per-thread constructors are functions called as the first thing from newly created threads. This can be used to initialize variables in thread-local storage, variables depending on the (tid_t) thread id, and to call setup functions that must be called from the thread itself. > > * Per-thread destructors are functions called (from the thread) as the last thing when a thread ends. > > > > At this time, I am seeking feedback on the concept and the proposed limitations. > > > > Processes have __attribute__(constructor/destructor) to set up functions to be called before main(). Nothing similar exists for threads, so we have to design it ourselves. > > > > The proposed per-thread constructors/destructors should not apply to all threads - only to threads created through the DPDK threads API. Agree? i'm not sure what threads you mean here, but i guess you mean only threads created with rte_thread_create? so this excludes the ``main'' thread and any threads created by the application via any other api that causes a thread to be created? - seems reasonable. > > > > DPDK has the RTE_INIT()/RTE_FINI() macros for adding process constructors/destructors at build time, so I propose a similar API, i.e. adding RTE_THREAD_INIT() and RTE_THREAD_FINI() macros to build a list of per-thread constructors and destructors at build time. > > > > Two functions that call the list of per-thread constructors respectively destructors will be introduced. > > > > The per-thread constructor function will be called from the newly created threads within DPDK: > > 1. EAL/SERVICE threads: In eal_thread_loop() before the loop. > > 2. CTRL threads: In ctrl_thread_init() before start_routine(). > > 3. Non-EAL threads: In rte_thread_register(). > > > > Are any thread types missing in the list above? > > I noticed a few drivers doing stuff behind EAL back.. you might want > to grep pthread_create. > They should probably be converted to control threads, or if there is a > reason, it could give more inputs on this topic. yes, there are drivers that probably pre-date the rte_ctrl_thread_create api that ought to be converted to using rte_ctrl_thread_create or ideally (if we can get more review / merged) the series where i have added the rte_control_thread_create api that operates with rte_thread_t. > > > > > > > > The per-thread destructor function will also be registered by the per-thread constructor, using the POSIX pthread_cleanup_push() function. > > What about Windows? > Cc: Tyler. yes, i had noticed this rfc and haven't had time to research properly to respond. in principal it seems like something that would be useful. in general if it is going to be part of eal we need to understand if the functionality can be feasibly provided for all supported platforms otherwise it doesn't belong in the abstraction layer. so long as it can be consistently provided on windows i certainly have no objection and if a windows implementation and working unit test is present i'm happy to prioritize review and testing to facilitate the work. i appreciate any assistance given that moves the windows port closer to parity with linux/freebsd. thanks! ty