From: Jakub Kicinski <kubakici@wp.pl>
To: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"oss-drivers@netronome.com" <oss-drivers@netronome.com>
Subject: Re: [PATCH net-next 02/12] nfp: set driver VF limit
Date: Sun, 28 May 2017 14:16:53 -0700 [thread overview]
Message-ID: <20170528141653.070fe118@cakuba.lan> (raw)
In-Reply-To: <BLUPR0701MB200496130E22B9820F7C1D858DF20@BLUPR0701MB2004.namprd07.prod.outlook.com>
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.
next prev parent reply other threads:[~2017-05-28 21:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-28 0:33 [PATCH net-next 00/12] nfp: pci core, hwmon, live mac addr change Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 01/12] nfp: add set_mac_address support while the interface is up Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 02/12] nfp: set driver VF limit Jakub Kicinski
2017-05-28 14:49 ` Mintz, Yuval
2017-05-28 21:16 ` Jakub Kicinski [this message]
2017-05-28 0:34 ` [PATCH net-next 03/12] nfp: don't set aux pointers if ioremap failed Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 04/12] nfp: only try to get to PCIe ctrl memory if BARs are wide enough Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 05/12] nfp: support long reads and writes with the cpp helpers Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 06/12] nfp: shorten CPP core probe logs Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 07/12] nfp: support variable NSP response lengths Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 08/12] nfp: add hwmon support Jakub Kicinski
2017-05-28 18:50 ` kbuild test robot
2017-05-28 0:34 ` [PATCH net-next 09/12] nfp: don't wait for resources indefinitely Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 10/12] nfp: fix print format for ring pointers in ring dumps Jakub Kicinski
2017-05-31 10:33 ` David Laight
2017-05-28 0:34 ` [PATCH net-next 11/12] nfp: don't add ring size to index calculations Jakub Kicinski
2017-05-28 0:34 ` [PATCH net-next 12/12] nfp: don't keep count for free buffers delayed kick Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170528141653.070fe118@cakuba.lan \
--to=kubakici@wp.pl \
--cc=Yuval.Mintz@cavium.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox