From: Don Dutile <ddutile@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-pci@vger.kernel.org, bhelgaas@google.com,
yuvalmin@broadcom.com, bhutchings@solarflare.com,
gregory.v.rose@intel.com, davem@davemloft.net
Subject: Re: [RFC] PCI: enable and disable sriov support via sysfs at per device level
Date: Tue, 02 Oct 2012 16:23:40 -0400 [thread overview]
Message-ID: <506B4D4C.3080101@redhat.com> (raw)
In-Reply-To: <CAE9FiQUd=sM3XaMKfJjnJq6mkugL7P=wEjdcMHtGjfe4ooRXUQ@mail.gmail.com>
On 10/02/2012 04:01 PM, Yinghai Lu wrote:
> On Mon, Oct 1, 2012 at 4:27 PM, Donald Dutile<ddutile@redhat.com> wrote:
>> Provide files under sysfs to determine the max number of vfs
>> an SRIOV-capable PCIe device supports, and methods to enable and
>> disable the vfs on a per device basis.
>>
>> Currently, VF enablement by SRIOV-capable PCIe devices is done
>> in driver-specific module parameters. If not setup in modprobe files,
>> it requires admin to unload& reload PF drivers with number of desired
>> VFs to enable. Additionally, the enablement is system wide: all
>> devices controlled by the same driver have the same number of VFs
>> enabled. Although the latter is probably desired, there are PCI
>> configurations setup by system BIOS that may not enable that to occur.
>>
>> Three files are created if a PCIe device has SRIOV support:
>> sriov_max_vfs -- cat-ing this file returns the maximum number
>> of VFs a PCIe device supports.
>> sriov_enable_vfs -- echo'ing a number to this file enables this
>> number of VFs for this given PCIe device.
>> -- cat-ing this file will return the number of VFs
>> currently enabled on this PCIe device.
>> sriov_disable_vfs -- echo-ing any number other than 0 disables all
>> VFs associated with this PCIe device.
>>
>> VF enable and disablement is invoked much like other PCIe
>> configuration functions -- via registered callbacks in the driver,
>> i.e., probe, release, etc.
>>
>> Note: I haven't had a chance to refactor an SRIOV PF driver
>> to test against; hoping to try ixgbe or igb in next couple days.
>> To date, just tested that cat-ing sriov_max_vfs works, and
>> cat-ing sriov_enable_vfs returns the correct number when
>> a PF driver has been loaded with VFs enabled via per-driver param,
>> e.g., modprobe igb max_vfs=4
>>
>> Send comments and I'll integrate as needed, while modifying
>> a PF driver to use this interface.
>>
>> Signed-off-by: Donald Dutile<ddutile@redhat.com>
>>
>> ---
>> drivers/pci/pci-sysfs.c | 186 ++++++++++++++++++++++++++++++++++++++++++++----
>> include/linux/pci.h | 2 +
>> 2 files changed, 175 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> index 6869009..1b5eab7 100644
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -404,6 +404,152 @@ static ssize_t d3cold_allowed_show(struct device *dev,
>> }
>> #endif
>>
>> +
>> +#ifdef CONFIG_PCI_IOV
>> +static ssize_t sriov_max_vfs_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct pci_dev *pdev;
>> +
>> + pdev = to_pci_dev(dev);
>> + return sprintf (buf, "%u\n", pdev->sriov->total);
>> +}
>> +
>> +bool pci_dev_has_sriov(struct pci_dev *pdev)
>> +{
>> + int ret = false;
>> + int pos;
>> +
>> + if (!pci_is_pcie(pdev))
>> + goto out;
>> +
>> + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_SRIOV);
>> + if (pos)
>> + ret = true;
>> +out:
>> + return ret;
>> +}
>> +
>> +static ssize_t sriov_enable_vfs_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct pci_dev *pdev;
>> + int nr_virtfn = 0;
>> +
>> + pdev = to_pci_dev(dev);
>> +
>> + if (pci_dev_has_sriov(pdev))
>> + nr_virtfn = pdev->sriov->nr_virtfn;
>> +
>> + return sprintf (buf, "%u\n", nr_virtfn);
>> +}
>> +
>> +static ssize_t sriov_enable_vfs_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct pci_dev *pdev;
>> + int num_vf_enabled = 0;
>> + unsigned long num_vfs;
>> + pdev = to_pci_dev(dev);
>> +
>> + if (!pci_dev_has_sriov(pdev))
>> + goto out;
>> +
>> + /* Requested VFs to enable< max_vfs
>> + * and none enabled already
>> + */
>> + if (strict_strtoul(buf, 0,&num_vfs)< 0)
>> + return -EINVAL;
>> +
>> + if ((num_vfs> pdev->sriov->total) ||
>> + (pdev->sriov->nr_virtfn != 0))
>> + return -EINVAL;
>> +
>> + /* Ready for lift-off! */
>> + if (pdev->driver&& pdev->driver->sriov_enable) {
>> + num_vf_enabled = pdev->driver->sriov_enable(pdev, num_vfs);
>> + }
>> +
>> +out:
>> + if (num_vf_enabled != num_vfs)
>> + printk(KERN_WARNING
>> + "%s: %04x:%02x:%02x.%d: Only %d VFs enabled \n",
>> + pci_name(pdev), pci_domain_nr(pdev->bus),
>> + pdev->bus->number, PCI_SLOT(pdev->devfn),
>> + PCI_FUNC(pdev->devfn), num_vf_enabled);
>> +
>> + return count;
>> +}
>> +
>> +static ssize_t sriov_disable_vfs_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct pci_dev *pdev;
>> +
>> + pdev = to_pci_dev(dev);
>> +
>> + /* make sure sriov device& at least 1 vf enabled */
>> + if (!pci_dev_has_sriov(pdev) ||
>> + (pdev->sriov->nr_virtfn == 0))
>> + goto out;
>> +
>> + /* Ready for landing! */
>> + if (pdev->driver&& pdev->driver->sriov_disable) {
>> + pdev->driver->sriov_disable(pdev);
>> + }
>> +out:
>> + return count;
>> +}
>> +
>> +struct device_attribute pci_dev_sriov_attrs[] = {
>> + __ATTR_RO(sriov_max_vfs),
>> + __ATTR(sriov_enable_vfs, (S_IRUGO|S_IWUSR|S_IWGRP),
>> + sriov_enable_vfs_show, sriov_enable_vfs_store),
>> + __ATTR(sriov_disable_vfs, (S_IWUSR|S_IWGRP),
>> + NULL, sriov_disable_vfs_store),
>> + __ATTR_NULL,
>> +};
>> +
>> +static int pci_sriov_create_sysfs_dev_files(struct pci_dev *dev)
>> +{
>> + int pos, i;
>> + int retval=0;
>> +
>> + if ((dev->is_physfn)&& pci_is_pcie(dev)) {
>> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_SRIOV);
>> + if (pos) {
>> + for (i = 0; attr_name(pci_dev_sriov_attrs[i]); i++) {
>> + retval = device_create_file(&dev->dev,&pci_dev_sriov_attrs[i]);
>> + if (retval) {
>> + while (--i>= 0)
>> + device_remove_file(&dev->dev,&pci_dev_sriov_attrs[i]);
>> + break;
>> + }
>> + }
>> + }
>> + }
>> + return retval;
>
>> +}
>> +
>> +static void pci_sriov_remove_sysfs_dev_files(struct pci_dev *dev)
>> +{
>> + int pos;
>> +
>> + if ((dev->is_physfn)&& pci_is_pcie(dev)) {
>> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_SRIOV);
>> + if (pos)
>> + device_remove_file(&dev->dev, pci_dev_sriov_attrs);
>> + }
>> +}
> ...
>> @@ -1203,14 +1365,18 @@ static int pci_create_capabilities_sysfs(struct pci_dev *dev)
>> goto error;
>> dev->reset_fn = 1;
>> }
>> +
>> + /* SRIOV */
>> + retval = pci_sriov_create_sysfs_dev_files(dev);
>> + if (retval)
>> + goto error;
>> +
>
> No, You should not use function for that.
>
> According to Greg, you should use group visible to do that.
>
> Please check the patches that i send out before.
>
> here I attached them again.
>
> Yinghai
Greg: Why not use the above functions?
and what are 'visible groups' ??
I tried to follow how other optional files were added,
which didn't involve groups or visibility. ... well, ok,
I followed optional symlinks in iov.c... which didn't use
group attributes, and these file seemed no different than other
pcie attributes which is handled in the pci-sysfs.c module
in this fashion.
Yinghai: As for looking at your patches, I did that.... and
they made no sense, i.e., I don't see the value/use/need of
'is_visible'. maybe if there was some decent
documentation/comments on this stuff, I could
confidently use them.... if they exist, please point me
in the that direction. if not, then point me to better examples.
Looking in Documentation, I didn't find anything to help.
Doing a grep on is_visible, all I see are flags being
added to subsystem-specific struct's, and the use of device_[create,remove]_files().
next prev parent reply other threads:[~2012-10-02 20:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-01 23:27 [RFC] PCI: enable and disable sriov support via sysfs at per device level Donald Dutile
2012-10-02 7:32 ` Yuval Mintz
2012-10-02 17:38 ` Don Dutile
2012-10-02 20:01 ` Yinghai Lu
2012-10-02 20:23 ` Don Dutile [this message]
2012-10-02 20:33 ` Yinghai Lu
2012-10-02 20:39 ` Greg Kroah-Hartman
2012-10-02 21:06 ` Don Dutile
2012-10-03 3:10 ` Greg Kroah-Hartman
2012-10-03 4:58 ` Yinghai Lu
2012-10-03 5:07 ` [PATCH 1/2] PCI: Add pci_dev_type Yinghai Lu
2012-10-03 5:07 ` [PATCH 2/2] PCI, sys: Use is_visable() with boot_vga attribute for pci_dev Yinghai Lu
2012-10-03 13:18 ` [RFC] PCI: enable and disable sriov support via sysfs at per device level Don Dutile
2012-10-03 17:51 ` [PATCH 0/5] PCI: per pci device sysfs set_max_vfs support Yinghai Lu
2012-10-03 17:51 ` [PATCH 1/5] PCI: Add pci_dev_type Yinghai Lu
2012-10-04 14:10 ` Konrad Rzeszutek Wilk
2012-10-03 17:51 ` [PATCH 2/5] PCI, sys: Use is_visable() with boot_vga attribute for pci_dev Yinghai Lu
2012-10-03 19:28 ` Greg Kroah-Hartman
2012-10-03 17:51 ` [PATCH 3/5] PCI: add set_max_vfs in pci_driver ops Yinghai Lu
2012-10-03 18:55 ` Don Dutile
2012-10-03 20:41 ` Yinghai Lu
2012-10-03 21:02 ` Don Dutile
2012-10-03 17:51 ` [PATCH 4/5] PCI: Add max_vfs in sysfs per pci device where supports Yinghai Lu
2012-10-04 14:15 ` Konrad Rzeszutek Wilk
2012-10-04 15:13 ` Yinghai Lu
2012-10-03 17:51 ` [PATCH 5/5] ixgbe: add driver set_max_vfs support Yinghai Lu
2012-10-03 17:57 ` Yinghai Lu
2012-10-03 18:45 ` Dan Carpenter
2012-10-03 18:45 ` Dan Carpenter
2012-10-03 18:47 ` Alexander Duyck
2012-10-03 18:47 ` Alexander Duyck
2012-10-03 19:02 ` Don Dutile
2012-10-03 19:16 ` Rose, Gregory V
2012-10-03 20:37 ` Yinghai Lu
2012-10-03 17:55 ` [RFC] PCI: enable and disable sriov support via sysfs at per device level Yinghai Lu
2012-10-03 18:16 ` Rose, Gregory V
2012-10-03 18:28 ` Yinghai Lu
2012-10-03 13:00 ` Konrad Rzeszutek Wilk
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=506B4D4C.3080101@redhat.com \
--to=ddutile@redhat.com \
--cc=bhelgaas@google.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=gregory.v.rose@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=yinghai@kernel.org \
--cc=yuvalmin@broadcom.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.