From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stable-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2ED6B43214 for <public@inbox.dpdk.org>; Fri, 27 Oct 2023 11:11:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2192540E68; Fri, 27 Oct 2023 11:11:28 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 6F3FB40272; Fri, 27 Oct 2023 11:11:25 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8E29A3200926; Fri, 27 Oct 2023 05:11:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 27 Oct 2023 05:11:24 -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= 1698397883; x=1698484283; bh=KTp4uJ29MmPtZZNIhOAwnvBK+rIyVM7OIZi ru8JS+64=; b=snDzG/8da3RJW9njgJ/ORrYo+c+Rr5vLybPsLJ9d7JHZHu5jy3r 7BDy8ctxuPKtsTVye5mjbqm/ZPH+FFdOJtxf1FrLm02RZBuSuntXKUO+D386DOWI MkhDjz/3MOgZMf9trxqeCo1FeJoxqzlxA6pWsyLEZAM2141r+k+E16DW4RShxQwS b9oIi85s1kfMVYCQaPW+QcNmlqo5rR0iaOjJsLsbfgqFpj1uusEOX3z94Qq7OCgp K2Ota/XaD/7ZiL/vTknYjawbBi85G5lpJFX14T450qMO1qFTa7jC8VMOfEwp2N5e f6M0rcTRhPLT4ui+oq+RAq+piWTSF8x7h4Q== 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= 1698397883; x=1698484283; bh=KTp4uJ29MmPtZZNIhOAwnvBK+rIyVM7OIZi ru8JS+64=; b=WXD1xxj4ep9jaRavORYqBntAprjDvgCLfWczIWkDUqNoZ5O6Qoi x5/+8OfWyBKc2WbD14MKbMkcXjRuhyD30WWABHXDlMpRTTnaCCnDM37QWXXw1q6I XUk1lThnc9jfbX/OYYQ/IACHBuYK/FzEm7k7TbuYI41kDHouyUt8B3b5pE2NMiYP 39JDtghgzX6CCskRWVe3KBOAWgsNG4ri/za7+NbtUq0YrVu1WaTIYf4v6GDg9Ayg KbYYn7dPHbDdOiCmthYBlDWOAZ3CfcLaIRplOsljjzDFpxfIgXhKWO4jRClb6RSz P2rKWGvC45fjEyDyYrmNl/xxPKQ99lXrU2Q== X-ME-Sender: <xms:un47ZZ2QbDtHX1n5abpPJ8b-Zznq-uQE_U4oBel0vTmQp3Tzwg9vNg> <xme:un47ZQG92JUyLCZZ1hjq7U8DipXpUp0tLJ4QnaVKITG-sa-KboR6sUjNv6X2Ezb_O J0VEu6henIsOrCrVg> X-ME-Received: <xmr:un47ZZ63Y5mM-DK6Er02pO8aYtYnI37TWAv-RaAcmbRjuS4yTq59hnTVYX1qJ1kHsdTMbKpKsTxPneQRvTO7es_bsA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeggddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:un47ZW2O-HSQ43BYkVmass8ITbezPtfkvbkeAqBPoeR7P-8eEBopFA> <xmx:un47ZcFWiizXEtqyy2rvWXrOy42x_GPOvrmdO8W3UyS4O3HlfFdiVQ> <xmx:un47ZX_yqhmGt1xf9KyE9-iHNmZBclzSIg0NAb7t5A60NYFsSnp1CQ> <xmx:u347ZXAksioKmsM0TOnJm2R5S_bxxhmtC6iBXhtr5BEEoOHsgCXh5A> Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Oct 2023 05:11:21 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> Cc: dev@dpdk.org, David Marchand <david.marchand@redhat.com>, stable@dpdk.org, Anatoly Burakov <anatoly.burakov@intel.com>, Tyler Retzlaff <roretzla@linux.microsoft.com>, Narcisa Vasile <navasile@linux.microsoft.com>, Stephen Hemminger <stephen@networkplumber.org>, Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>, Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> Subject: Re: [PATCH v6 1/1] eal/unix: allow creating thread with real-time priority Date: Fri, 27 Oct 2023 11:11:19 +0200 Message-ID: <2088214.KlZ2vcFHjT@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFA3@smartserver.smartshare.dk> References: <20231024125416.798897-1-thomas@monjalon.net> <20231027081158.1358064-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35E9EFA3@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches <stable.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/stable>, <mailto:stable-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/stable/> List-Post: <mailto:stable@dpdk.org> List-Help: <mailto:stable-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/stable>, <mailto:stable-request@dpdk.org?subject=subscribe> Errors-To: stable-bounces@dpdk.org 27/10/2023 10:45, Morten Br=F8rup: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Friday, 27 October 2023 10.09 > >=20 > > When adding an API for creating threads, > > the real-time priority has been forbidden on Unix. > >=20 > > There is a known issue with ring behaviour, > > but it should not be completely forbidden. > >=20 > > Real-time thread can block some kernel threads on the same core, > > making the system unstable. > > That's why a sleep is added in the test thread, > > and a warning is logged when using real-time priority. > >=20 > > Fixes: ca04c78b6262 ("eal: get/set thread priority per thread > > identifier") > > Fixes: ce6e911d20f6 ("eal: add thread lifetime API") > > Fixes: a7ba40b2b1bf ("drivers: convert to internal control threads") > > Cc: stable@dpdk.org > >=20 > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net> > > Acked-by: Morten Br=F8rup <mb@smartsharesystems.com> > > --- >=20 > [...] >=20 > > enum rte_thread_priority { > > + /** Normal thread priority, the default. */ > > RTE_THREAD_PRIORITY_NORMAL =3D 0, > > - /**< normal thread priority, the default */ > > + /** > > + * Highest thread priority, use with caution. > > + * WARNING: System may be unstable because of a real-time busy > > loop. > > + * @see rte_thread_yield_realtime(). >=20 > Please remove the reference to the now non-existing function. >=20 > Also, I'd prefer to move the warning comments (about real-time threads ha= ving priority over kernel threads, and issues with rte_ring) up here, so it= goes into the public API documentation. Yes OK, thanks for the careful review. >=20 > > + */ > > RTE_THREAD_PRIORITY_REALTIME_CRITICAL =3D 1, > > - /**< highest thread priority allowed */ > > }; > >=20 > > /** > > diff --git a/lib/eal/unix/rte_thread.c b/lib/eal/unix/rte_thread.c > > index 278d8d342d..17ffb86c17 100644 > > --- a/lib/eal/unix/rte_thread.c > > +++ b/lib/eal/unix/rte_thread.c > > @@ -33,6 +33,8 @@ static int > > thread_map_priority_to_os_value(enum rte_thread_priority eal_pri, int > > *os_pri, > > int *pol) > > { > > + static bool warned; > > + > > /* Clear the output parameters. */ > > *os_pri =3D sched_get_priority_min(SCHED_OTHER) - 1; > > *pol =3D -1; > > @@ -51,6 +53,17 @@ thread_map_priority_to_os_value(enum > > rte_thread_priority eal_pri, int *os_pri, > > sched_get_priority_max(SCHED_OTHER)) / 2; > > break; > > case RTE_THREAD_PRIORITY_REALTIME_CRITICAL: > > + /* > > + * WARNING: Real-time busy loop takes priority on kernel > > threads, > > + * making the system unstable. > > + * There is also a known issue when using > > rte_ring. > > + */ > > + if (!warned) { > > + RTE_LOG(NOTICE, EAL, > > + "Real-time thread is unstable if polling > > without sleep.\n"); > > + warned =3D true; > > + } >=20 > Is it 100 % certain that the system becomes unstable if not sleeping or u= sing blocking system calls from a real-time thread? > And technically, it's not the thread itself that becomes unstable. >=20 > How about: > "System may be unstable unless real-time thread uses blocking system call= s or sleeps." > or: > "Real-time thread usually requires the use of blocking system calls or sl= eeps." > or something else. Yes something like that looks better. I will try to find a short sentence. >=20 > My ACK is still valid. >=20 >=20