netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).