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

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] [day] [month] [year] [list]

Message-ID: <20230224112207.055165bd@kernel.org>
Date:   Fri, 24 Feb 2023 11:22:07 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Nambiar, Amritha" <amritha.nambiar@...el.com>
Cc:     Alexander H Duyck <alexander.duyck@...il.com>,
        <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <edumazet@...gle.com>, <pabeni@...hat.com>,
        "Saeed Mahameed" <saeed@...nel.org>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: Re: Kernel interface to configure queue-group parameters

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 :(