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