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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 20 Nov 2022 16:24:18 -0600 From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com> To: Leon Romanovsky <leon@...nel.org>, "Saleem, Shiraz" <shiraz.saleem@...el.com> CC: Jakub Kicinski <kuba@...nel.org>, Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>, "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>, "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>, Bjorn Helgaas <bhelgaas@...gle.com> Subject: Re: [PATCH net-next 00/13] resource management using devlink reload On 11/18/2022 11:31 AM, Leon Romanovsky wrote: > On Fri, Nov 18, 2022 at 02:23:50PM +0000, Saleem, Shiraz wrote: >>> Subject: Re: [PATCH net-next 00/13] resource management using devlink reload >>> >>> On Thu, Nov 17, 2022 at 07:36:18PM -0800, Jakub Kicinski wrote: >>>> On Thu, 17 Nov 2022 19:38:48 +0200 Leon Romanovsky wrote: >>>>> I don't think that management of PCI specific parameters in devlink >>>>> is right idea. PCI has his own subsystem with rules and assumptions, >>>>> netdev shouldn't mangle them. >>>> Not netdev, devlink, which covers netdev, RDMA and others. >>> devlink is located in net/*, it is netdev. >>> Regarding RDMA, it is not fully accurate. We use devlink to convey information to >>> FW through pci device located in netdev. Some of such parameters are RDMA >>> related. However, we don't configure RDMA properties through devlink, there is a >>> special tool for that (rdmatool). >> rdmatool though is usable only once the rdma driver probe() completes and the ib_device is registered. >> And cannot be used for any configurations at driver init time. > Like I said, we use devlink to configure FW and "core" device to which > ib_device is connected. We don't configure RDMA specific properties, but > only device specific ones. I don't think this patch series is configuring any PCI specific parameters OR per-PCI device parameters. The FW splits the device level MSI-X vectors across its PFs(1 per port). Each PF manages its own MSI-X vectors and distributes them across the different functions associated with that PF. So far the PF driver has been doing this with a hard-coded policy implemented within the driver. We are exposing that policy via devlink and allowing a host admin to split the MSI-X vectors that are assigned to a PF by the FW across its different functions (PF, all its VFs, all its SFs and RDMA) based on the use cases/workload running on the host.
Powered by blists - more mailing lists