netdev - Re: [PATCH net-next 00/13] resource management using devlink reload

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:   Mon, 14 Nov 2022 19:09:36 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "jiri@...dia.com" <jiri@...dia.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "Lobakin, Alexandr" <alexandr.lobakin@...el.com>,
        "Drewek, Wojciech" <wojciech.drewek@...el.com>,
        "Czapnik, Lukasz" <lukasz.czapnik@...el.com>,
        "Saleem, Shiraz" <shiraz.saleem@...el.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Ismail, Mustafa" <mustafa.ismail@...el.com>,
        "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>,
        "Raczynski, Piotr" <piotr.raczynski@...el.com>,
        "Ertman, David M" <david.m.ertman@...el.com>,
        "Kaliszczuk, Leszek" <leszek.kaliszczuk@...el.com>
Subject: Re: [PATCH net-next 00/13] resource management using devlink reload

On Mon, Nov 14, 2022 at 04:58:57PM +0000, Keller, Jacob E wrote:
> 
> 
> > -----Original Message-----
> > From: Samudrala, Sridhar <sridhar.samudrala@...el.com>
> > Sent: Monday, November 14, 2022 7:31 AM
> > To: Leon Romanovsky <leon@...nel.org>; Michal Swiatkowski
> > <michal.swiatkowski@...ux.intel.com>
> > Cc: netdev@...r.kernel.org; davem@...emloft.net; kuba@...nel.org;
> > pabeni@...hat.com; edumazet@...gle.com; intel-wired-lan@...ts.osuosl.org;
> > jiri@...dia.com; Nguyen, Anthony L <anthony.l.nguyen@...el.com>; Lobakin,
> > Alexandr <alexandr.lobakin@...el.com>; Drewek, Wojciech
> > <wojciech.drewek@...el.com>; Czapnik, Lukasz <lukasz.czapnik@...el.com>;
> > Saleem, Shiraz <shiraz.saleem@...el.com>; Brandeburg, Jesse
> > <jesse.brandeburg@...el.com>; Ismail, Mustafa <mustafa.ismail@...el.com>;
> > Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>; Raczynski, Piotr
> > <piotr.raczynski@...el.com>; Keller, Jacob E <jacob.e.keller@...el.com>; Ertman,
> > David M <david.m.ertman@...el.com>; Kaliszczuk, Leszek
> > <leszek.kaliszczuk@...el.com>
> > Subject: Re: [PATCH net-next 00/13] resource management using devlink reload
> > 
> > On 11/14/2022 7:23 AM, Leon Romanovsky wrote:
> > > On Mon, Nov 14, 2022 at 01:57:42PM +0100, Michal Swiatkowski wrote:
> > >> Currently the default value for number of PF vectors is number of CPUs.
> > >> Because of that there are cases when all vectors are used for PF
> > >> and user can't create more VFs. It is hard to set default number of
> > >> CPUs right for all different use cases. Instead allow user to choose
> > >> how many vectors should be used for various features. After implementing
> > >> subdevices this mechanism will be also used to set number of vectors
> > >> for subfunctions.
> > >>
> > >> The idea is to set vectors for eth or VFs using devlink resource API.
> > >> New value of vectors will be used after devlink reinit. Example
> > >> commands:
> > >> $ sudo devlink resource set pci/0000:31:00.0 path msix/msix_eth size 16
> > >> $ sudo devlink dev reload pci/0000:31:00.0
> > >> After reload driver will work with 16 vectors used for eth instead of
> > >> num_cpus.
> > > By saying "vectors", are you referring to MSI-X vectors?
> > > If yes, you have specific interface for that.
> > > https://lore.kernel.org/linux-pci/20210314124256.70253-1-leon@kernel.org/
> > 
> > This patch series is exposing a resources API to split the device level MSI-X vectors
> > across the different functions supported by the device (PF, RDMA, SR-IOV VFs
> > and
> > in future subfunctions). Today this is all hidden in a policy implemented within
> > the PF driver.
> > 
> > The patch you are referring to seems to be providing an interface to change the
> > msix count for a particular VF. This patch is providing a interface to set the total
> > msix count for all the possible VFs from the available device level pool of
> > msix-vectors.
> > 
> 
> It looks like we should implement both: resources to configure the "pool" of available vectors for each VF, and the sysfs VF Interface to allow configuring individual VFs.

Yes, to be aligned with PCI spec and see coherent lspci output for VFs.

Thanks

> 
> Thanks,
> Jake