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 4B51543212; Fri, 27 Oct 2023 09:19:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C577402DF; Fri, 27 Oct 2023 09:19:05 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 1BA164029A for ; Fri, 27 Oct 2023 09:19:04 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 02AB220723; Fri, 27 Oct 2023 09:19:02 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v3 0/2] allow creating thread with real-time priority X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Oct 2023 09:19:00 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFA0@smartserver.smartshare.dk> In-Reply-To: <3061820.CbtlEUcBR6@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v3 0/2] allow creating thread with real-time priority Thread-Index: AdoIRch+1jYh6F7yQhmQq9rlpRa38AAWzEMQ References: <20231024125416.798897-1-thomas@monjalon.net> <2651241.BddDVKsqQX@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9EF9E@smartserver.smartshare.dk> <3061820.CbtlEUcBR6@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" Cc: "Bruce Richardson" , , "David Marchand" , , "Tyler Retzlaff" 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 > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday, 26 October 2023 21.51 >=20 > 26/10/2023 18:50, Morten Br=F8rup: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > Sent: Thursday, 26 October 2023 18.07 [...] > > > For average realtime thread, I suggest the API > > > rte_thread_yield_realtime() > > > which could wait for 1 ms or less by default. > > > > If we introduce a yield() function, it should yield according to the > O/S scheduling policy, e.g. the rest of the time slice allocated to = the > thread by the O/S scheduler (although that might not be available for > real-time prioritized threads in Linux). I don't think we can make it > O/S agnostic. > > > > I don't think it should wait a fixed amount of time - we already = have > rte_delay_us_sleep() for that. > > > > In my experiments with power saving, I ended up with a varying sleep > duration, depending on traffic load. The l3fwd-power example also uses > a varying sleep duration depending on traffic load. >=20 > I feel you lost the goal of this: schedule other threads (especially > kernel threads). > So we don't care about the sleep duration at all, > except we want it minimal while allowing scheduling. I do understand the goal: We want to relinquish the CPU core briefly, so = the RT-priority thread gives way for other threads to run on the same = CPU core. But I don't think it is possible for an RT-priority thread to yield = without waiting in a blocking call or waiting for an explicit timeout. = This is the reason why Stephen wants the big fat warning sign when = assigning RT-priority to a thread. This will happen if we don't provide something for the RT-priority = thread to wait for: The application thread calls "yield()", e.g. sleep(0), to pass control = to the kernel scheduler. The kernel scheduler looks at all tasks available. The application = thread has RT-priority and is ready to run, so the kernel scheduler will = pick this thread for running. Only if other RT-priority threads are = ready to run, perhaps one of those will be picked. No other threads will = be picked, not even kernel threads (because RT-priority is higher than = the priority of the kernel threads). [...] > Windows should be fine with Sleep(0). Reading the Win32 API documentation [1] carefully, it think it will = generally behave like the Linux scheduler. It says: "A value of zero causes the thread to relinquish the remainder of its = time slice to any other thread of equal priority that is ready to run. = If there are no other threads of equal priority ready to run, the = function returns immediately, and the thread continues execution. This = behavior changed starting with Windows Server 2003." How I interpret this is: The Windows scheduler will not relinquish the = CPU core to lower priority threads when calling Sleep(0). If the = application thread has RT-priority, the scheduler will immediately pick = the same thread. Only if other RT-priority threads are ready to run, one = of those will be picked. [1]: = https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-= sleep