netdev - Re: [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with queues and new 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:   Wed, 28 Sep 2022 14:02:57 +0200
From:   "Wilczynski, Michal" <michal.wilczynski@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Edward Cree <ecree.xilinx@...il.com>, <netdev@...r.kernel.org>,
        <alexandr.lobakin@...el.com>, <dchumak@...dia.com>,
        <maximmi@...dia.com>, <jiri@...nulli.us>,
        <simon.horman@...igine.com>, <jacob.e.keller@...el.com>,
        <jesse.brandeburg@...el.com>, <przemyslaw.kitszel@...el.com>
Subject: Re: [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with
 queues and new parameters

On 9/27/2022 2:16 AM, Jakub Kicinski wrote:
> On Fri, 23 Sep 2022 17:46:35 +0200 Wilczynski, Michal wrote:
>> Also reconfiguration from the VM, would need to be handled by the VF
>> driver i.e iavf.
>> So the solution would get much more complex I guess, since we would need
>> to implement communication between ice-iavf, through virtchnl I guess.
> Yup, but it's the correct way to solve your problem AFAICT.
>
> AFAIU you only want to cater to simple cases where the VF and PF
> are in the same control domain, which is not normal, outside of
> running DPDK apps. Sooner or later someone will ask for queuing
> control from the VFs and you're have to redesign the whole thing.

Hmm, so I guess the queue part of this patch is not well liked.
I wonder if I should re-send this patch with just the implementation
of devlink-rate, and minor changes in devlink, like exposing functions,
so the driver can export initial configurations. This still brings some 
value,
cause the user would still be able to modify at least the upper part of the
tree.

We can still discuss how the final solution should look like, but i'm 
out of ideas
when it comes for a inside VF interface, (like we discussed tc-htb in 
current form
doesn't really work for us).

Thanks,
Michał