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

Date:   Thu, 16 Feb 2023 02:34:37 -0800
From:   "Nambiar, Amritha" <amritha.nambiar@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Alexander H Duyck <alexander.duyck@...il.com>
CC:     <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 2/8/2023 4:36 PM, Jakub Kicinski wrote:
> On Tue, 07 Feb 2023 08:28:56 -0800 Alexander H Duyck wrote:
>> I think much of this depends on exactly what functionality we are
>> talking about.
> 
> Right, maybe we need to take a page out of the container's book and
> concede that best we can do is provide targeted APIs for slices of
> the problem. Which someone in user space would have to combine.
> 

Agree, a common interface for various parameters for the queue-group 
does not seem like a practical approach and the interface to use is 
largely driven by the functionality itself.

>>> 4. Devlink:
>>>      Pros:
>>>      - New parameters can be added without any changes to the kernel or
>>> userspace.
>>>
>>>      Cons:
>>>      - Queue/Queue_group is a function-wide entity, Devlink is for
>>> device-wide stuff. Devlink being device centric is not suitable for
>>> queue parameters such as rates, NAPI etc.
>>
>> Yeah, I wouldn't expect something like this to be a good fit.
> 
> Devlink has the hierarchical rate API for example.
> Maybe we should (re)consider adding top level nodes for RSS contexts
> there?