netdev - Re: [RFC net-next (what uAPI?) ice: add support for more than 16 RSS queues for VF

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: <20240429185941.6229b944@kernel.org>
Date: Mon, 29 Apr 2024 18:59:41 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
 "Knitter, Konrad" <konrad.knitter@...el.com>, "Samudrala, Sridhar"
 <sridhar.samudrala@...el.com>, "Brandeburg, Jesse"
 <jesse.brandeburg@...el.com>, Mateusz Polchlopek
 <mateusz.polchlopek@...el.com>, Ahmed Zaki <ahmed.zaki@...el.com>, "Simon
 Horman" <horms@...nel.org>, Michal Schmidt <mschmidt@...hat.com>, Paolo
 Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>, Pawel Chmielewski
 <pawel.chmielewski@...el.com>, "Nguyen, Anthony L"
 <anthony.l.nguyen@...el.com>
Subject: Re: [RFC net-next (what uAPI?) ice: add support for more than 16
 RSS queues for VF

On Fri, 26 Apr 2024 15:22:02 +0200 Przemek Kitszel wrote:
> ## devlink resources (with current API)
> `devlink resource` is compelling, partially given the name sounds like a
> perfect match. But when we dig just a little bit, the current Path+sizes
> (min,max,step) is totally off to what is the most elegant picture of the
> situation. In order to fit into existing uAPI, I would need to register
> VFs as PF's resource, then GLOBAL LUT and PF LUT as a sub resource to
> that (each VF gets two entries under it; plus two additional ones for
> PF) I don't like it, I also feel like there is not that much use of
> current resources API (it's not natural to use it for distribution, only
> for limitation).

Can you share more on how that would look like? 

From the description it does not sound so bad. Maybe with some CLI / UI
changes it will be fine?

> ## devlink resources (with extended API)
> It is possible to extend current `devlink resource` so instead of only
> Path+size, there would be also Path+Owner option to use.
> The default state for ice driver would be that PFs owns PF LUTs, GLOBAL
> LUTs are all free.
> 
> example proposed flow to assign a GLOBAL LUT to VF0 and PF LUT to VF1:
> pf=0000:03:00.0  # likely more meaningful than VSI idx, but open for
> vf0=0000:03:00.1 #                                       suggestions
> vf1=0000:03:00.2
> devlink resource set pci/$pf path /lut/lut_table_512 owner $pf
> devlink resource set pci/$pf path /lut/lut_table_2048 owner free
> devlink resource set pci/$pf path /lut/lut_table_512 owner $vf0
> devlink resource set pci/$pf path /lut/lut_table_2048 owner $vf1

Don't we want some level of over-subscription to be allowed?