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