> From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Tuesday, 24 October 2023 14.54 > > When adding an API for creating threads, > the real-time priority has been forbidden on Unix. > > There is a known issue with ring behaviour, > but it should not be completely forbidden. > > 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: sta...@dpdk.org > > Signed-off-by: Thomas Monjalon <tho...@monjalon.net> > ---
[...] > @@ -815,7 +815,9 @@ Known Issues > > 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>
