From: Greg Rose <gregory.v.rose@intel.com>
To: Yuval Mintz <yuvalmin@broadcom.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Ariel Elior <ariele@broadcom.com>,
Eilon Greenstein <eilong@broadcom.com>
Subject: Re: New commands to configure IOV features
Date: Wed, 19 Sep 2012 08:53:06 -0700 [thread overview]
Message-ID: <20120919085306.00006af9@unknown> (raw)
In-Reply-To: <5059A767.2090307@broadcom.com>
On Wed, 19 Sep 2012 14:07:19 +0300
Yuval Mintz <yuvalmin@broadcom.com> wrote:
> >>> Back to the original discussion though--has anyone got any ideas
> >>> about the best way to trigger runtime creation of VFs? I don't
> >>> know what the binary APIs looks like, but via sysfs I could see
> >>> something like
> >>>
> >>> echo number_of_new_vfs_to_create >
> >>> /sys/bus/pci/devices/<address>/create_vfs
> >>>
> >>> Something else that occurred to me--is there buy-in from driver
> >>> maintainers? I know the Intel ethernet drivers (what I'm most
> >>> familiar
> >>> with) would need to be substantially modified to support
> >>> on-the-fly addition of new vfs. Currently they assume that the
> >>> number of vfs is known at module init time.
> >>
> >> Why couldn't rtnl_link_ops be used for this. It is already the
> >> preferred interface to create vlan's, bond devices, and other
> >> virtual devices? The one issue is that do the created VF's exist
> >> in kernel as devices or only visible to guest?
> >
> > I would say that rtnl_link_ops are network oriented and not
> > appropriate for something like a storage controller or graphics
> > device, which are two other common SR-IOV capable devices.
>
> Hi Dave,
>
> We're currently fine-tuning our SRIOV support, which we will shortly
> send upstream.
>
> We've encountered a problem though - all drivers currently supporting
> SRIOV do so with the usage of a module param: e.g., 'max_vfs' for
> ixgbe, 'num_vfs' for benet, etc.
> The SRIOV feature is disabled by default on all the drivers; it can
> only be enabled via usage of the module param.
>
> We don't want the lack of SRIOV module param in the bnx2x driver to be
> the bottle-neck when we'll submit the SRIOV feature upstream, and we
> also don't want to enable SRIOV by default (following the same logic
> of other drivers; most users don't use SRIOV and it would strain their
> resources).
>
> As we see it, there are several possible ways of solving the issue:
> 1. Use some network-tool (e.g., ethtool).
> 2. Implement a standard sysfs interface for PCIe devices, as SRIOV is
> not solely network-related (this should be done via the PCI linux
> tree).
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.
- Greg
LAN Access Division
Intel Corp.
> 3. Implement a module param in our bnx2x code.
>
> We would like to know what's your preferred method for solving this
> issue, and to hear if you have another (better?) method by which we
> can add this kind of support.
>
> Thanks,
> Yuval Mintz
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-09-19 15:53 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 11:17 New commands to configure IOV features Yuval Mintz
2012-05-07 15:16 ` Greg Rose
2012-06-26 12:21 ` Yuval Mintz
2012-06-26 16:13 ` Alexander Duyck
2012-06-26 17:19 ` Greg Rose
2012-07-01 11:09 ` Yuval Mintz
2012-07-09 18:39 ` Ben Hutchings
2012-07-09 21:13 ` Chris Friesen
2012-07-16 9:19 ` Yuval Mintz
2012-07-17 19:29 ` Don Dutile
2012-07-17 21:08 ` Chris Friesen
2012-07-17 21:11 ` David Miller
2012-07-20 15:27 ` Chris Friesen
2012-07-20 15:56 ` Don Dutile
2012-07-20 17:42 ` Ben Hutchings
2012-07-20 19:29 ` Chris Friesen
2012-07-20 20:01 ` Ben Hutchings
2012-07-20 20:15 ` Don Dutile
2012-07-20 23:42 ` Chris Friesen
2012-07-21 0:52 ` Rose, Gregory V
2012-07-23 14:03 ` Don Dutile
2012-07-23 15:09 ` Chris Friesen
2012-07-23 17:06 ` Rose, Gregory V
2012-07-23 18:36 ` Stephen Hemminger
2012-07-23 18:40 ` Rose, Gregory V
2012-09-19 11:07 ` Yuval Mintz
2012-09-19 15:53 ` Greg Rose [this message]
2012-09-19 19:44 ` Ben Hutchings
2012-09-19 22:17 ` Yinghai Lu
2012-09-19 22:46 ` Ben Hutchings
2012-09-20 0:19 ` Yinghai Lu
2012-09-20 1:23 ` Ben Hutchings
2012-09-20 2:27 ` Yinghai Lu
2012-09-20 3:08 ` Subhendu Ghosh
2012-09-20 15:39 ` Rose, Gregory V
2012-09-21 5:50 ` Yinghai Lu
2012-09-21 17:35 ` Ben Hutchings
2012-09-21 19:23 ` Yinghai Lu
2012-09-21 18:06 ` Don Dutile
2012-09-21 19:49 ` Yinghai Lu
2012-09-21 20:08 ` Don Dutile
2012-09-23 15:49 ` Yuval Mintz
2012-09-24 17:37 ` Don Dutile
2012-09-30 6:39 ` Yuval Mintz
2012-10-01 14:12 ` Don Dutile
2012-09-19 17:49 ` David Miller
2012-07-23 16:37 ` Rose, Gregory V
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=20120919085306.00006af9@unknown \
--to=gregory.v.rose@intel.com \
--cc=ariele@broadcom.com \
--cc=davem@davemloft.net \
--cc=eilong@broadcom.com \
--cc=netdev@vger.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 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).