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

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 28 Apr 2025 14:29:03 -0700 Joe Damato wrote:
> 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.

The way I see it - the traditional permission model doesn't extend 
in any meaningful way to network settings. All the settings are done 
by some sort of helper or intermediary which implements its own
privilege model.

My thinking is more that the "global" settings are basically "system"
settings. There is a high-perf app running which applied its own
settings to its own queues. The remaining queues belong to the "system".
Now if you for some reason want to modify the settings of the "system
queues" you really don't want to override the app specific settings.

The weakness in my argument is that you probably really shouldn't mess
with system level settings on a live system, according to devops.
But life happens, and visibility is not perfect so somethings you have
to poke to test a theory..