Subject: Re: Kernel interface to configure queue-group parameters

From: Jakub Kicinski <[email-masked]>
Date: Fri, 24 Feb 2023 11:22:07 -0800

On Fri, 24 Feb 2023 01:14:15 -0800 Nambiar, Amritha wrote:
> On 2/16/2023 9:32 AM, Jakub Kicinski wrote:
> > On Thu, 16 Feb 2023 02:35:35 -0800 Nambiar, Amritha wrote:  
> >> Right. Something like /sys/class/net/<iface>/napis/napi<0-N>
> >> Maybe, initially there would be as many napis as queues due to 1:1
> >> association, but as the queues bitmap is tuned for the napi, only those
> >> napis that have queue[s] associated with it would be exposed.  
> > 
> > Forget about using sysfs, please. We've been talking about making
> > "queues first class citizen", mapping to pollers is part of that
> > problem space. And it's complex enough to be better suited for netlink.  
> 
> Okay. Can ethtool netlink be an option for this? For example,
> 
> ethtool --show-napis
> 	Lists all the napi instances and associated queue[s] list for each napi 
> for the specified network device.
> 
> ethtool --set-napi
> 	Configure the attributes (say, queue[s] list) for each napi
> 	
> 	napi <napi_id>
> 		The napi instance to configure
> 	
> 	queues <q_id1, q_id2, ...>
> 		The queue[s] that are to be serviced by the napi instance.

The netdev-genl family is a better target.

But the work is doing the refactoring within the kernel to abstract
all this stuff away from the drivers, so that the kernel has 
a stronger model of queues. If we just expose the calls to the drivers
directly we'll end up with a lot of code duplication and not-so-subtle
differences between vendors :(