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]

Message-ID: <20220926171623.3778dc74@kernel.org>
Date:   Mon, 26 Sep 2022 17:16:23 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Wilczynski, Michal" <michal.wilczynski@...el.com>
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 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.