netdev - Re: New commands to configure IOV features

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]

Message-ID: <1348094773.2636.85.camel@bwh-desktop.uk.solarflarecom.com>
Date:	Wed, 19 Sep 2012 23:46:13 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Greg Rose <gregory.v.rose@...el.com>,
	Yuval Mintz <yuvalmin@...adcom.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Ariel Elior <ariele@...adcom.com>,
	Eilon Greenstein <eilong@...adcom.com>,
	linux-pci <linux-pci@...r.kernel.org>
Subject: Re: New commands to configure IOV features

On Wed, 2012-09-19 at 15:17 -0700, Yinghai Lu wrote:
> On Wed, Sep 19, 2012 at 12:44 PM, Ben Hutchings
> <bhutchings@...arflare.com> wrote:
> > On Wed, 2012-09-19 at 08:53 -0700, Greg Rose wrote:
> >> I was not able to attend the Linux conference held at the end of August
> >> myself but coworkers of mine here at Intel informed that method 2 here
> >> seems to be the preferred approach.  Perhaps some folks who attended
> >> the the conference can chime in with more specifics.
> >
> > There really wasn't much more specific discussion.  Bjorn's summary of
> > the mini-summit <http://lwn.net/Articles/514113/> says:
> >
> >> SR-IOV Management
> >>
> >>     Currently drivers implement module parameters like "max_vfs".  This means
> >>     all devices claimed by the driver get the same number of VFs, and you can't
> >>     change anything without unloading and reloading the driver.
> >>
> >>     Consensus that we should try to implement a knob for this in sysfs so it
> >>     can be generic (not in each driver) and set individually for each device.
> >
> > I don't think any implementation has been posted to the linux-pci list
> 
> please check attached three patches...
[...]
> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
> +++ linux-2.6/drivers/pci/pci-sysfs.c
> @@ -459,6 +459,30 @@ boot_vga_show(struct device *dev, struct
>  }
>  struct device_attribute vga_attr = __ATTR_RO(boot_vga);
>  
> +static ssize_t
> +max_vfs_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> +       struct pci_dev *pdev = to_pci_dev(dev);
> +
> +       return sprintf(buf, "%u\n", pdev->max_vfs);
> +}
> +static ssize_t
> +max_vfs_store(struct device *dev, struct device_attribute *attr,
> +                const char *buf, size_t count)
> +{
> +       unsigned long val;
> +       struct pci_dev *pdev = to_pci_dev(dev);
> +
> +       if (strict_strtoul(buf, 0, &val) < 0)
> +               return -EINVAL;
> +
> +       pdev->max_vfs = val;
> +
> +       return count;
> +}
[...]

Then what would actually trigger creation of the VFs?  There's no way we
can assume that some sysfs attribute will be written before the PF
driver is loaded (what if it's built-in?).  I thought the idea was to
add a driver callback that would be called when the sysfs attribute was
written.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html