RE: Thread priority for background tasks

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, 30 April 2025 21.45
> 
> On Wed, 30 Apr 2025 20:40:52 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > There are only two thread priorities in the enum rte_thread_priority:
> Normal and Real-time Critical.
> >
> > I would like to poll ethdev counters, collect garbage and perform
> other jitter non-sensitive tasks in a control thread with lower
> priority than my ordinary control threads, so it will be preempted by
> any work ready for my ordinary control threads.
> >
> > Which DPDK API am I supposed to use to assign this below-normal
> priority to my "background" control thread?
> >
> > Or: Aren't we missing a priority like Linux' SCHED_BATCH?
> 
> Short answer: if your application is running on Linux, only ever use
> Normal.
> DPDK applications usually never sleep and this will starve the OS and
> cause instability.

I was asking for the opposite of Critical priority.

For the sake of discussion, imagine a (registered or unregistered) non-EAL thread doing something like this:
loop {
	poll_counters(); // 1 ms execution time
	sleep(99 ms);
}

With normal scheduling priority, it will rack up a lot of scheduling credits during sleep(), so it might not be preempted by other threads while executing poll_counters().

But if some other thread (on the same CPU core) changes state from Sleeping to Runnable, I want it to preempt the counter polling thread.
This other thread could be a control plane application, e.g. a DNS Server, which shouldn't suffer up to 1 ms scheduling lag if it becomes Runnable the instant the counter polling thread started executing poll_counters().

So I'm looking for a DPDK API to apply a "low priority" scheduling policy, like SCHED_BATCH, to the counter polling thread.

> 
> Long answer:
> Realtime critical was added for Windows, which needs it and doesn't do
> the
> same real RT behavior. Might work on FreeBSD, not sure how the
> scheduler works.
> 
> On Linux, it is possible to use but only if the application is not a
> 100% polling.
> (i.e a real time application not a polling application).
> It needs to regularly sleep to allow non-RT kernel threads to run,
> otherwise things
> like disk writes that are pending on that CPU may not happen, leading
> to filesystem
> corruption. Or hangs.
> 
> Bottom line:
> Real time critical means this needs to run for a short time now (i.e
> safety switch).
> RT does not mean this is more important overall, or needs to run
> faster.