On Wed, Oct 25, 2023 at 03:15:49PM +0200, Thomas Monjalon wrote: > 24/10/2023 18:04, Stephen Hemminger: > > On Tue, 24 Oct 2023 15:55:13 +0200 > > Morten Brørup <m...@smartsharesystems.com> wrote: > > > > > > > > > > 4. It MAY be used by preemptible multi-producer and/or preemptible > > > > multi- > > > > consumer pthreads whose scheduling policy are all SCHED_OTHER(cfs), > > > > SCHED_IDLE > > > > or SCHED_BATCH. User SHOULD be aware of the performance penalty before > > > > using > > > > it. > > > > > > > > - 5. It MUST not be used by multi-producer/consumer pthreads, whose > > > > scheduling policies are SCHED_FIFO or SCHED_RR. > > > > + 5. It MUST not be used by multi-producer/consumer pthreads > > > > + whose scheduling policies are ``SCHED_FIFO`` > > > > + or ``SCHED_RR`` (``RTE_THREAD_PRIORITY_REALTIME_CRITICAL``). > > > > > > Do the RTS or HTS ring modes make any difference here? > > > > > > Anyway, I agree that real-time priority should not be forbidden on Unix. > > > > > > Acked-by: Morten Brørup <m...@smartsharesystems.com> > > > > Please add a big warning message in the rte_thread.c and the documentation > > to describe the problem. Need to have the "you have been warned" action. > > Yes I can add more warnings. > > > Use of RT priority is incompatible with 100% poll mode as is typically done > > in DPDK applications. A real time thread has higher priority than other > > necessary > > kernel threads on the same CPU. Therefore if the RT thread never sleeps, > > critical > > system actions such as delayed writes, network packet processing and timer > > updates > > will not happen which makes the system unstable. > > Yes, and it is shown by the test on loongarch: > DPDK:fast-tests / threads_autotest TIMEOUT 80.01s > http://mails.dpdk.org/archives/test-report/2023-October/488760.html > > I'll try to pass the test by adding a sleep in the test thread. >
"sched_yield()" rather than sleep perhaps? Might better convey the intention of the call.
