netdev - Re: [PATCH net-next v5] Add support to set napi threaded for individual napi

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aA_zH52V-5qYku3M@LQ3V64L9R2>
Date: Mon, 28 Apr 2025 14:29:03 -0700
From: Joe Damato <jdamato@...tly.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
	Samiullah Khawaja <skhawaja@...gle.com>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	almasrymina@...gle.com, willemb@...gle.com, mkarsten@...terloo.ca,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5] Add support to set napi threaded for
 individual napi

On Mon, Apr 28, 2025 at 11:38:45AM -0700, Jakub Kicinski wrote:
> On Mon, 28 Apr 2025 11:12:34 -0700 Joe Damato wrote:
> > On Sat, Apr 26, 2025 at 10:41:10AM -0400, Willem de Bruijn wrote:
> > > This also reminds me of /proc/sys/net/ipv4/conf/{all, default, .. }
> > > API. Which confuses me to this day.
> 
> Indeed. That scheme has the additional burden of not being consistently 
> enforced :/ So I'm trying to lay down some rules (in the doc linked
> upthread).
> 
> The concern I have with the write all semantics is what happens when
> we delegate the control over a queue / NAPI to some application or
> container. Is the expectation that some user space component prevents
> the global settings from being re-applied when applications using
> dedicated queues / NAPIs are running?

I think this is a good question and one I spent a lot of time
thinking through while hacking on the per-NAPI config stuff.

One argument that came to my mind a few times was that to write to
the global path requires admin and one might assume:
  - an admin knows what they are doing and why they are doing a
    global write
  - there could be a case where the admin does really want to reset
    every NAPIs setting on the system in one swoop

I suppose you could have the above (an admin override, so to speak)
but still delegate queues/NAPIs to apps to configure as they like?

I think the admin override is kinda nice if an app starts doing
something weird, but maybe that's too much complexity.