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 F29DB431FC; Wed, 25 Oct 2023 19:06:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6EEEA40A6F; Wed, 25 Oct 2023 19:06:59 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 7B14840042 for ; Wed, 25 Oct 2023 19:06:57 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9FEB832009A0; Wed, 25 Oct 2023 13:06:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 25 Oct 2023 13:06:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type: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=fm3; t= 1698253615; x=1698340015; bh=2JWHKtYXxKx0H/xO6rypSxbbDmi2WcA/pQK cVC0wRyE=; b=R08nxgzg2KrnKzjkOf2juxIin+HK1Uc0fEFRfjEuAB35mESDTB3 lk0WRMBUrMKxgeZCUUP/gcR4gjh9mdr0OI4KcafErANjt0x3rdE4kEOHbQC5EqaB WPNFD4gehGNQyT6h7IML8aCoBa480+UFu6HPZedyYRqjv4E66kEcuB+vugJtlDo/ 3MREZXbyifMyuS90ULIL4xdgUdK9Po9bwjoYX7Z693yGdMtFaqcJRRHtGTCBr3e5 aB14+61FgMqvt+gIWdwWIyuD7bTuW3ky+DtNW/L8pXBYtw0oh38VrHZLITPrl+rB +YjmxSxeBkqcY+Tm0yGo5/K1MJ+emZv60WA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type: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=fm3; t= 1698253615; x=1698340015; bh=2JWHKtYXxKx0H/xO6rypSxbbDmi2WcA/pQK cVC0wRyE=; b=d++AT4rluG5NibCsVLrMeNMsPFipYWxlyQV/QNLQnJ6iL1GyfaZ ZYHARZM6+aavcLFZBsbxP7J3IDanEDxMe9ZZ16oS0fs6S8E/gMdFQeaiIku/+VsZ O4Zw6UNYH0mIES3dgJSUQK35eDTu4BLO0ywha2iARIYsqKny1p/JHrpeJc07bPS+ seBEMxkHKowSBOnfzLSykhUJrx1NWWeednjE6ByCPglF0xvbcNKSCEwPkeRk9bwN zm+1puWTQ2XUa0lK3UXY5uQ26VzYUgCHv5Weu0CuKztZ0Zzb2/WCc6GfkR2vj+pY 9WKItafxwycD2n4qtbx9Mkjv3c6uhnG7LSQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrledtgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 Oct 2023 13:06:53 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, David Marchand , Dmitry Kozlyuk , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam Subject: Re: [PATCH v3 1/2] eal: add thread yield functions Date: Wed, 25 Oct 2023 19:06:52 +0200 Message-ID: <2167870.Mh6RI2rZIc@thomas> In-Reply-To: References: <20231024125416.798897-1-thomas@monjalon.net> <20231025163352.1076755-2-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 25/10/2023 18:40, Bruce Richardson: > On Wed, Oct 25, 2023 at 06:31:10PM +0200, Thomas Monjalon wrote: > > When running real-time threads, we may need to force scheduling > > kernel threads or other real-time threads. > > New functions are added to address these cases. > > > > The yield functions should not have any interest for normal threads. > > Note: other purposes may be addressed with rte_pause() or rte_delay_*(). > > > > Signed-off-by: Thomas Monjalon > > --- > > lib/eal/include/rte_thread.h | 22 ++++++++++++++++++++++ > > lib/eal/unix/rte_thread.c | 16 ++++++++++++++++ > > lib/eal/version.map | 4 ++++ > > lib/eal/windows/rte_thread.c | 15 +++++++++++++++ > > 4 files changed, 57 insertions(+) > > > > diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h > > index 8da9d4d3fb..139cafac96 100644 > > --- a/lib/eal/include/rte_thread.h > > +++ b/lib/eal/include/rte_thread.h > > @@ -183,6 +183,28 @@ int rte_thread_join(rte_thread_t thread_id, uint32_t *value_ptr); > > */ > > int rte_thread_detach(rte_thread_t thread_id); > > > > +/** > > + * Allow another thread to run on the same CPU core. > > + * > > + * Lower priority threads may not be scheduled. > > + * > > + * Especially useful in real-time thread priority > > + * to schedule other real-time threads. > > + * @see RTE_THREAD_PRIORITY_REALTIME_CRITICAL > > + */ > > +__rte_experimental > > +void rte_thread_yield(void); > > + > > +/** > > + * Unblock a CPU core running busy in a real-time thread. > > + * > > + * Especially useful in real-time thread priority > > + * to avoid a busy loop blocking vital threads on a core. > > + * @see RTE_THREAD_PRIORITY_REALTIME_CRITICAL > > + */ > > +__rte_experimental > > +void rte_thread_yield_realtime(void); > > + > > /** > > * Get the id of the calling thread. > > * > > diff --git a/lib/eal/unix/rte_thread.c b/lib/eal/unix/rte_thread.c > > index 36a21ab2f9..92b4e53adb 100644 > > --- a/lib/eal/unix/rte_thread.c > > +++ b/lib/eal/unix/rte_thread.c > > @@ -5,9 +5,11 @@ > > > > #include > > #include > > +#include > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -227,6 +229,20 @@ rte_thread_detach(rte_thread_t thread_id) > > return pthread_detach((pthread_t)thread_id.opaque_id); > > } > > > > +void > > +rte_thread_yield(void) > > +{ > > + sched_yield(); > > +} > > + > > +void > > +rte_thread_yield_realtime(void) > > +{ > > + /* A simple yield may not be enough to schedule kernel threads. */ > > + struct timespec wait = {.tv_nsec = 1}; > > + nanosleep(&wait, NULL); > > +} > > + > While I realise we discussed this earlier, and I also was the original > suggester of using sched_yield, I think just having just one function using > sleep is probably best after all. I think there is a value to have a simple yield function for scheduling between multiple real-time threads without sleep overhead (not sure about the overhead). If there is not much overhead, then a single function is OK. Note I'm preparing a new version with a simple yield implemented with the lighter SwitchToThread() on Windows.