Re: Thread priority for background tasks

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, May 01, 2025 at 09:05:32AM +0200, Morten Brørup wrote:
> > 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.
> 

Does this need to be done in DPDK? Unless you need to target Windows, would
using the standard Unix/Posix scheduling/pthread APIs directly not be best,
rather than having us try to wrap all such things inside DPDK APIs? I worry
about scope creep for such things, with us ending up wrapping a whole bunch
of scheduling stuff into DPDK that we should not need to do.

/Bruce