netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: David Miller <davem@davemloft.net>
Cc: "shemminger@vyatta.com" <shemminger@vyatta.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"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 17:54:55 -0700	[thread overview]
Message-ID: <49CAD25F.4080705@intel.com> (raw)
In-Reply-To: <20090325.165847.234084422.davem@davemloft.net>

David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Wed, 25 Mar 2009 15:33:31 -0700
> 
>> 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.
> 
> I have to agree with Stephen that the way to create new links
> of virtual and similar devices is to use rtnl_link.
> 
> We have very good infrastructure for this, and if I understand
> things correctly iproute2 might even work with an igb using
> rtnl_link with zero modifications to the tool sources.
> 
> Please fix this up, it's a very reasonable request for such
> a large new piece of driver infrastructure.  And since this is
> a new driver, you have no time constraints for submission either.
> 

Thanks for allowing me more time, but the issue isn't the igbvf driver. 
  The part that Stephen is referencing will be an issue in the igb 
driver.  That is why I pointed him to 
http://patchwork.ozlabs.org/patch/23471/ since it is the part that 
contains the code that he has issues with.

Since the issue isn't the igbvf driver there is no reason for it to be 
held up.  If you want to revert the offending patch feel free to and 
what I will do is send a patch out that just statically set the number 
of VFs to 7 if the kernel and device supports enabling SR-IOV.  I didn't 
want to take that approach since it means that it disables multi-queue 
for igb on those devices but I feel like I have been backed into a 
corner on this and don't have many other options.

Thanks,

Alex












  reply	other threads:[~2009-03-26  0:54 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
2009-03-25 23:58     ` David Miller
2009-03-26  0:54       ` Alexander Duyck [this message]
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=49CAD25F.4080705@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).