Re: [RFC net-next 0/5] Suspend IRQs during preferred busy poll

[Jakub Kicinski <kuba@kernel.org>]

On Sun, 18 Aug 2024 10:51:04 -0400 Martin Karsten wrote:
> >> I believe this would take away flexibility without gaining much. You'd
> >> still want some sort of admin-controlled 'enable' flag, so you'd still
> >> need some kind of parameter.
> >>
> >> When using our scheme, the factor between gro_flush_timeout and
> >> irq_suspend_timeout should *roughly* correspond to the maximum batch
> >> size that an application would process in one go (orders of magnitude,
> >> see above). This determines both the target application's worst-case
> >> latency as well as the worst-case latency of concurrent applications, if
> >> any, as mentioned previously.  
> > 
> > Oh is concurrent applications the argument against a very high
> > timeout?  
> 
> Only in the error case. If suspend_irq_timeout is large enough as you 
> point out above, then as long as the target application behaves well, 
> its batching settings are the determining factor.

Since the discussion is still sort of going on let me ask something
potentially stupid (I haven't read the paper, yet). Are the cores
assumed to be fully isolated (ergo the application can only yield 
to the idle thread)? Do we not have to worry about the scheduler
deciding to schedule the process out involuntarily?