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