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. > Multiple DPDK users have learned this the hard way.
