From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>
Subject: Re: [net-next PATCH v3] igbvf: add new driver to support 82576 virtual functions
Date: Wed, 25 Mar 2009 15:33:31 -0700 [thread overview]
Message-ID: <49CAB13B.7070601@intel.com> (raw)
In-Reply-To: <20090325150322.40e0a1e6@nehalam>
Stephen Hemminger wrote:
> On Wed, 25 Mar 2009 14:52:48 -0700
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This adds an igbvf driver to handle virtual functions provided by the
>> igb driver when SR-IOV has been enabled. A virtual function is a
>> lightweight pci-e function that supports a single queue and shares
>> resources with the 82576 physical function contained within the igb
>> driver.
>>
>> To spawn virtual functions from the igb driver all that is needed is to
>> issue a echo X > /sys/class/ethY/num_vfs. X can be a value between 0 and
>> 7, 0 will disable SR-IOV functionality for the port and is the default. If
>> the num_vfs sysfs entry is not present then the device does not have SR-IOV
>> capability enabled either in software or hardware.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Please don't use sysfs for this.
> Instead build a proper rtnl_link netlink interface (see macvlan).
>
> Intel doesn't invent unique hardware, other vendors will do the same
> thing (or follow your lead), so doing it right the first time for these
> kind of devices makes sense.
The sysfs part of this is already in net-next as it isn't part of the
igbvf driver it is part of igb. It was added in over a month ago:
http://patchwork.ozlabs.org/patch/23471/
I will see what we can do to make use of a netlink interface. I'm
honestly not even sure if it will work well for this kind of setup since
the VF driver won't even be running on the same OS in most cases. For
now the sysfs code in igb is actually quite minimal, and the main goal
was to keep the interface as simple as possible which is what I have done.
We are already planning to make a number of changes to support Host
configuration of the guest interfaces for 2.6.31, and a number of those
included sysfs entries that I had rejected for this release. What I can
probably do is see about trying to make all of those changes be pushed
over to a netlink interface since it would make much more sense when we
have multiple items to configure other than just setting the number of VFs.
Thanks,
Alex
next prev parent reply other threads:[~2009-03-25 22:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 21:52 [net-next PATCH v3] igbvf: add new driver to support 82576 virtual functions Jeff Kirsher
2009-03-25 22:00 ` Jeff Kirsher
2009-03-25 22:03 ` Stephen Hemminger
2009-03-25 22:33 ` Alexander Duyck [this message]
2009-03-25 23:58 ` David Miller
2009-03-26 0:54 ` Alexander Duyck
2009-03-26 2:33 ` Yu Zhao
2009-03-26 3:16 ` David Miller
2009-03-26 13:05 ` Patrick McHardy
2009-03-26 3:12 ` David Miller
2009-03-26 3:21 ` Roland Dreier
2009-03-26 3:33 ` David Miller
2009-03-26 3:27 ` Alexander Duyck
2009-03-26 3:34 ` David Miller
2009-03-27 0:30 ` [ RFC ] igb: first draft of igb rtnl_link_ops interface for vf creation (was Re: [net-next PATCH v3] igbvf: add new driver to support 82576 virtual functions) Alexander Duyck
2009-03-27 5:35 ` Patrick McHardy
2009-03-27 15:22 ` [ RFC ] igb: first draft of igb rtnl_link_ops interface for vf creation Alexander Duyck
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=49CAB13B.7070601@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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;
as well as URLs for NNTP newsgroup(s).