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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240819193610.5f416199@kernel.org>
Date: Mon, 19 Aug 2024 19:36:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Martin Karsten <mkarsten@...terloo.ca>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>, Joe Damato <jdamato@...tly.com>
Cc: Samiullah Khawaja <skhawaja@...gle.com>, Stanislav Fomichev
 <sdf@...ichev.me>, netdev@...r.kernel.org, amritha.nambiar@...el.com,
 sridhar.samudrala@...el.com, Alexander Lobakin
 <aleksander.lobakin@...el.com>, Alexander Viro <viro@...iv.linux.org.uk>,
 Breno Leitao <leitao@...ian.org>, Christian Brauner <brauner@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jan Kara
 <jack@...e.cz>, Jiri Pirko <jiri@...nulli.us>, Johannes Berg
 <johannes.berg@...el.com>, Jonathan Corbet <corbet@....net>, "open
 list:DOCUMENTATION" <linux-doc@...r.kernel.org>, "open list:FILESYSTEMS
 (VFS and infrastructure)" <linux-fsdevel@...r.kernel.org>, open list
 <linux-kernel@...r.kernel.org>, Lorenzo Bianconi <lorenzo@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>
Subject: Re: [RFC net-next 0/5] Suspend IRQs during preferred busy poll

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?