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

[Joe Damato <jdamato@fastly.com>]

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.