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
| ||
|
Message-ID: <20170528141653.070fe118@cakuba.lan> Date: Sun, 28 May 2017 14:16:53 -0700 From: Jakub Kicinski <kubakici@...pl> To: "Mintz, Yuval" <Yuval.Mintz@...ium.com> Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "oss-drivers@...ronome.com" <oss-drivers@...ronome.com> Subject: Re: [PATCH net-next 02/12] nfp: set driver VF limit On Sun, 28 May 2017 14:49:58 +0000, Mintz, Yuval wrote: > > pf->limit_vfs = nfp_rtsym_read_le(pf->cpp, "nfd_vf_cfg_max_vfs", > > &err); > > if (!err) > > - return; > > + return pci_sriov_set_totalvfs(pf->pdev, pf->limit_vfs); > > While you're at it, If you're going to enforce the limit at the PCI level, > shouldn't you retire 'limit_vfs' altogether? I don't think so, unfortunately. Sometimes FW sets this value to 0, which means no VFs should be used, but the PCIe subsystem uses 0 as "driver limit not set" :( I will put that in the commit message. > BTW, under which conditions would you expect to find a difference > in the maximal number of VFs? It mostly comes down to how FW projects choose to partition PCIe-side resources on the NFP. Some project for which SR-IOV is not a priority may want to disable it completely. The NFP is very software-driven, including most of PCIe interactions, descriptor formats etc. It's really up to particular projects to shape how the card works.
Powered by blists - more mailing lists