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 900B4A04FF; Thu, 24 Mar 2022 09:31:09 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2EBAB410FC; Thu, 24 Mar 2022 09:31:09 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 222FF40141 for ; Thu, 24 Mar 2022 09:31:08 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 6E3C620DEC82; Thu, 24 Mar 2022 01:31:07 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6E3C620DEC82 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1648110667; bh=9iGabEzHUibmVEdU5pImmU5aTG/Ym2WGUposUJbfQr0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iFtXsnxsdc5631CuKPzIb3WZbDBaEwymD9E+Lv5WpxEsLRHCVVqxsZaS6haxDQN7j Q+76XtJMo3+qSI6PkRSTuQFZNdc4+ESnlI5UYF98aVwtIr1jiwJTsh/stXVy3n/D39 XzPzpKsUGluy2sJNugoWQM83/sXiFxWPJo+n5lvY= Date: Thu, 24 Mar 2022 01:31:07 -0700 From: Tyler Retzlaff To: David Marchand Cc: dev@dpdk.org, thomas@monjalon.net, Bruce Richardson , Dmitry Kozlyuk , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam Subject: Re: [PATCH] eal: factorize lcore main loop Message-ID: <20220324083107.GA28494@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20220323093001.20618-1-david.marchand@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220323093001.20618-1-david.marchand@redhat.com> 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, Mar 23, 2022 at 10:30:01AM +0100, David Marchand wrote: > All OS implementations provide the same main loop. > Introduce helpers (shared for Linux and FreeBSD) to handle synchronisation > between main and threads and factorize the rest as common code. > Thread id are now logged as string in a common format across OS. > > Signed-off-by: David Marchand > --- > I had this patch in store for a long time. > I don't particularly care about it, it's not fixing anything. > But it seems a good cleanup/consolidation, so I rebased it and I am > sending it to get feedback. > ... snip ... > diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c > index 684bea166c..256de91abc 100644 > --- a/lib/eal/common/eal_common_thread.c > +++ b/lib/eal/common/eal_common_thread.c > @@ -9,6 +9,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -163,6 +164,77 @@ __rte_thread_uninit(void) > RTE_PER_LCORE(_lcore_id) = LCORE_ID_ANY; > } > > +/* main loop of threads */ > +__rte_noreturn void * > +eal_thread_loop(__rte_unused void *arg) > +{ > + char cpuset[RTE_CPU_AFFINITY_STR_LEN]; > + pthread_t thread_id = pthread_self(); > + unsigned int lcore_id; > + int ret; > + > + /* retrieve our lcore_id from the configuration structure */ > + RTE_LCORE_FOREACH_WORKER(lcore_id) { > + if (thread_id == lcore_config[lcore_id].thread_id) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ i can see that in practice this isn't a problem since the linux implementation of pthread_create(3) stores to pthread_t *thread before executing start_routine. but strictly speaking i don't think the pthread_create api contractually guarantees that the thread id is stored before start_routine runs. so this is relying on an internal implementation detail. https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_create.html "Upon successful completion, pthread_create() shall store the ID of the created thread in the location referenced by thread." https://man7.org/linux/man-pages/man3/pthread_create.3.html "Before returning, a successful call to pthread_create() stores the ID of the new thread in the buffer pointed to by thread; this identifier is used to refer to the thread in subsequent calls to other pthreads functions." it doesn't really say when it does this in relation to start_routine running. depends how hair splitty you want to be about it. but since you're revamping the code you might be interested in addressing it. ty