RE: [E1000-devel] [Bug 56981] New: [SR-IOV] Intel I350 NIC VF cannot work in a Windows 2008 guest.
Adding Ashish Shah. IIRC Windows 2008 isn't supported by the VF driver but I may be mistaken. Ashish should know. - Greg > -Original Message- > From: Ren, Yongjie [mailto:yongjie@intel.com] > Sent: Monday, April 22, 2013 6:16 PM > To: e1000-de...@lists.sourceforge.net; kvm@vger.kernel.org > Subject: Re: [E1000-devel] [Bug 56981] New: [SR-IOV] Intel I350 NIC VF > cannot work in a Windows 2008 guest. > > Added e1000-devel list to see whether this's a known issue. > > Best Regards, > Yongjie (Jay) > > > > -Original Message- > > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] > > On Behalf Of bugzilla-dae...@bugzilla.kernel.org > > Sent: Monday, April 22, 2013 10:41 PM > > To: kvm@vger.kernel.org > > Subject: [Bug 56981] New: [SR-IOV] Intel I350 NIC VF cannot work in a > > Windows 2008 guest. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=56981 > > > >Summary: [SR-IOV] Intel I350 NIC VF cannot work in a > > Windows > > 2008 guest. > >Product: Virtualization > >Version: unspecified > > Kernel Version: 3.9.0-rc3 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: kvm > > AssignedTo: virtualization_...@kernel-bugs.osdl.org > > ReportedBy: yongjie@intel.com > > Regression: No > > > > > > Environment: > > > > Host OS (ia32/ia32e/IA64):ia32e > > Guest OS (ia32/ia32e/IA64):ia32e > > Guest OS Type (Linux/Windows):Windows > > kvm.git Commit:79558f112fc0352e057f7b5e158e3d88b8b62c60 > > qemu-kvm Commit:8912bdea01e8671e59fe0287314379be9c1f40ec > > Host Kernel Version:3.9.0-rc3 > > Hardware: Sandy Bridge - EP > > > > > > Bug detailed description: > > -- > > The assigned Intel I350 NIC VF (a igbvf) cannot work in a Windows 2008 > > guest. > > > > 1. If the guest is Windows 7/8/2012 or RHEL6.x , the Intel I350 NIC VF > > can work fine in the guest. > > 2. Intel 82576 NIC VF (also igbvf) can work in a Windows 2008 guest. > > > > > > Reproduce steps: > > > > 1. ./pcistub.sh -h 0b:10.0 ( to hide a device) > > 2. qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device > > pci-assign,host=0b:10.0 -net none -hda win2k8.img > > > > Current result: > > > > Intel I350 NIC VF cannot work in win2k8 guest > > > > Expected result: > > > > Intel I350 NIC VF can work in win2k8 guest > > > > -- > > Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email > > --- You are receiving this mail because: --- You are watching > > the assignee of the bug. > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in the > > body of a message to majord...@vger.kernel.org More majordomo info at > > http://vger.kernel.org/majordomo-info.html > -- > > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use our > toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > ___ > E1000-devel mailing list > e1000-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/e1000-devel > To learn more about Intel® Ethernet, visit > http://communities.intel.com/community/wired -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
> -Original Message- > From: Jason Gao [mailto:pkill.2...@gmail.com] > Sent: Thursday, November 08, 2012 8:00 PM > To: Rose, Gregory V > Cc: Kirsher, Jeffrey T; linux-kernel; netdev; kvm; e1000- > de...@lists.sourceforge.net > Subject: Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources > for SR-IOV) > > > The BIOS in your machine doesn't support SR-IOV. You'll need to ask the > manufacturer for a BIOS upgrade, if in fact one is available. Sometimes > they're not. > > very thanks Greg,my server Dell R710 with latest BIOS version and option > for SR-IOV(SR-IOV Global Enable->Enabled) opened,I'm confused that Does > R710 provide full support for SR-IOV, kernel or ixgbe driver's bug? but > I'm not sure where the problem lies,anyone has any > experience about this? . I use a Dell R710 for all my SR-IOV testing and it works fine but I had to acquire a special BIOS from Dell to get it to work. As I said, you'll want to contact them and make sure you've got the correct BIOS. The error you're seeing, "not enough MMIO resources" has been an issue with the BIOS 100% of the times that we've run into it. In any case, it is NOT a driver bug. The driver has nothing to do with allocation of MMIO space reservation for VF devices. The message you're seeing pops up when the driver calls pci_enable_sriov(). There is nothing the driver can do to force that call to be successful. I've added Sibai Li to this response. She should be able to get the BIOS version string off of one of our working Dell R710s. Sibai, Could you please reply to this message with that information? Thanks, - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
> -Original Message- > From: Chris Wright [mailto:chr...@redhat.com] > Sent: Wednesday, November 30, 2011 3:01 PM > To: Ben Hutchings > Cc: Chris Wright; Rose, Gregory V; Roopa Prabhu; net...@vger.kernel.org; > da...@davemloft.net; s...@us.ibm.com; dragos.tatu...@gmail.com; > kvm@vger.kernel.org; a...@arndb.de; m...@redhat.com; mc...@broadcom.com; > dwa...@cisco.com; shemmin...@vyatta.com; eric.duma...@gmail.com; > ka...@trash.net; be...@cisco.com > Subject: Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering > support for passthru mode > > * Ben Hutchings (bhutchi...@solarflare.com) wrote: > > On Wed, 2011-11-30 at 13:04 -0800, Chris Wright wrote: > > > I agree that it's confusing. Couldn't you simplify your ascii art > > > (hopefully removing hw assumptions about receive processing, and > > > completely ignoring vlans for the moment) to something like: > > > > > > |RX > > > v > > > ++-+ > > > | +--++| > > > | | RX MAC filter || > > > | |and port select|| > > > | +---+| > > > |/|\ | > > > | / | \ match 2| > > > | / v \ | > > > | /match \| > > > |/ 1 |\ | > > > | / | \ | > > > |match / | \ | > > > | 0 / | \| > > > |v|v | > > > |||| | > > > ++++---+ > > > ||| > > > PF VF 1 VF 2 > > > > > > And there's an unclear number of ways to update "RX MAC filter and > port > > > select" table. > > > > > > 1) PF ndo_set_mac_addr > > > I expect that to be implicit to match 0. > > > > > > 2) PF ndo_set_rx_mode > > > Less clear, but I'd still expect these to implicitly match 0 > > > > > > 3) PF ndo_set_vf_mac > > > I expect these to be an explicit match to VF N (given the interface > > > specifices which VF's MAC is being programmed). > > > > I'm not sure whether this is supposed to implicitly add to the MAC > > filter or whether that has to be changed too. That's the main > > difference between my models (a) and (b). > > I see now. I wasn't entirely clear on the difference before. It's also > going to be hw specific. I think (Intel folks can verify) that the > Intel SR-IOV devices have a single global unicast exact match table, > for example. > > > There's also PF ndo_set_vf_vlan. > > Right, although I had mentioned I was trying to limit just to MAC > filtering to simplify. > > > > 4) VF ndo_set_mac_addr > > > This one may or may not be allowed (setting MAC+port if the VF is > owned > > > by a guest is likely not allowed), but would expect an implicit VF N. > > > > > > 5) VF ndo_set_rx_mode > > > Same as 4) above. > > > > So this is where we are today. > > Cool, good that we agree there. > > > > 6) PF or VF? ndo_set_rx_filter_addr > > > The new proposal, which has an explicit VF, although when it's VF_SELF > > > I'm not clear if this is just the same as 5) above? > > > > > > Have I missed anything? > > > > Any physical port can be bridged to a mixture of guests with and without > > their own VFs. Packets sent from a guest with a VF to the address of a > > guest without a VF need to be forwarded to the PF rather than the > > physical port, but none of the drivers currently get to know about those > > addresses. > > To clarify, do you mean something like this? > >physical port > | > +++ > | +-+ | > | | VEB | | > | +-+ | > |/ | \| > | /|\ | > | / | \ | > +-+--+--+-+ > | | | > PFVF 1VF 2 > / | | > +---+---+ VM4 +---+---+ > | sw | |macvtap| > | switch| +---+---+ > +-+-+-+-+ | >/ | \VM5 > / | \ > VM1 VM2 VM3 > > This has VMs 1-3 hanging of the PF via a linux bridge (traditional hv > switching), VM4 directly owning VF1 (pci device assignement), and VM5 > indirectly owning VF2 (macvtap passthrough, that started this whole > thing). > > So,
RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Roopa Prabhu
> Sent: Tuesday, October 18, 2011 11:26 PM
> To: net...@vger.kernel.org
> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de;
> kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net;
> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com;
> eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com
> Subject: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering
> support for passthru mode
>
> v1 version of this RFC patch was posted at
> http://www.spinics.net/lists/netdev/msg174245.html
>
> Today macvtap used in virtualized environment does not have support to
> propagate MAC, VLAN and interface flags from guest to lowerdev.
> Which means to be able to register additional VLANs, unicast and multicast
> addresses or change pkt filter flags in the guest, the lowerdev has to be
> put in promisocous mode. Today the only macvlan mode that supports this is
> the PASSTHRU mode and it puts the lower dev in promiscous mode.
>
> PASSTHRU mode was added primarily for the SRIOV usecase. In PASSTHRU mode
> there is a 1-1 mapping between macvtap and physical NIC or VF.
>
> There are two problems with putting the lowerdev in promiscous mode (ie
> SRIOV
> VF's):
> - Some SRIOV cards dont support promiscous mode today (Thread on
> Intel
> driver indicates that http://lists.openwall.net/netdev/2011/09/27/6)
> - For the SRIOV NICs that support it, Putting the lowerdev in
> promiscous mode leads to additional traffic being sent up to the
> guest virtio-net to filter result in extra overheads.
>
> Both the above problems can be solved by offloading filtering to the
> lowerdev hw. ie lowerdev does not need to be in promiscous mode as
> long as the guest filters are passed down to the lowerdev.
>
> This patch basically adds the infrastructure to set and get MAC and VLAN
> filters on an interface via rtnetlink. And adds support in macvlan and
> macvtap
> to allow set and get filter operations.
>
> Earlier version of this patch provided the TUNSETTXFILTER macvtap
> interface
> for setting address filtering. In response to feedback, This version
> introduces a netlink interface for the same.
>
> Response to some of the questions raised during v1:
>
> - Netlink interface:
> This patch provides the following netlink interface to set mac and
> vlan
> filters :
> [IFLA_RX_FILTER] = {
> [IFLA_ADDR_FILTER] = {
> [IFLA_ADDR_FILTER_FLAGS]
> [IFLA_ADDR_FILTER_UC_LIST] = {
> [IFLA_ADDR_LIST_ENTRY]
> }
> [IFLA_ADDR_FILTER_MC_LIST] = {
> [IFLA_ADDR_LIST_ENTRY]
> }
> }
> [IFLA_VLAN_FILTER] = {
> [IFLA_VLAN_BITMAP]
> }
> }
>
> Note: The IFLA_VLAN_FILTER is a nested attribute and contains only
> IFLA_VLAN_BITMAP today. The idea is that the IFLA_VLAN_FILTER can
> be extended tomorrow to use a vlan list option if some
> implementations
> prefer a list instead.
>
> And it provides the following rtnl_link_ops to set/get MAC/VLAN
> filters:
>
>int (*set_rx_addr_filter)(struct net_device
> *dev,
>struct nlattr *tb[]);
>int (*set_rx_vlan_filter)(struct net_device
> *dev,
> struct nlattr *tb[]);
>size_t (*get_rx_addr_filter_size)(const struct
> net_device *dev);
>size_t (*get_rx_vlan_filter_size)(const struct
> net_device *dev);
>int (*fill_rx_addr_filter)(struct sk_buff *skb,
> const struct net_device
> *dev);
>int (*fill_rx_vlan_filter)(struct sk_buff *skb,
> const struct net_device
> *dev);
>
>
> Note: The choice of rtnl_link_ops was because I saw the use case for
> this in virtual devices that need to do filtering in sw like
> macvlan
> and tun. Hw devices usually have filtering in hw with netdev->uc and
> mc lists to indicate active filters. But I can move from
> rtnl_link_ops
> to netdev_ops if that is the preferred way to go and if there is a
> need to support this interface on all kinds of interfaces.
> Please suggest.
>
> - Protection against address spoofing:
> - This patch adds filtering support only for macvtap PASSTHRU
> Mode. PASSTHRU mode is used mainly with SRIOV VF's. And SRIOV VF's
> come with anti mac/vlan spoofing support. (Recently added
> IFLA_VF_
RE: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address filtering support for passthru mode
> -Original Message- > From: Roopa Prabhu [mailto:ropra...@cisco.com] > Sent: Monday, October 31, 2011 10:09 AM > To: Rose, Gregory V; net...@vger.kernel.org > Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; kvm@vger.kernel.org; > a...@arndb.de; m...@redhat.com; da...@davemloft.net; mc...@broadcom.com; > dwa...@cisco.com; shemmin...@vyatta.com; eric.duma...@gmail.com; > ka...@trash.net; be...@cisco.com > Subject: Re: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address > filtering support for passthru mode > > > > > On 10/31/11 9:38 AM, "Rose, Gregory V" wrote: > > >> -Original Message- > >> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] > >> On Behalf Of Roopa Prabhu > >> Sent: Friday, October 28, 2011 7:34 PM > >> To: net...@vger.kernel.org > >> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; kvm@vger.kernel.org; > >> a...@arndb.de; m...@redhat.com; da...@davemloft.net; Rose, Gregory V; > >> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > >> eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com > >> Subject: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address filtering > >> support for passthru mode > >> > >> v2 -> v3 > >> - Moved set and get filter ops from rtnl_link_ops to netdev_ops > >> - Support for SRIOV VFs. > >> [Note: The get filters msg might get too big for SRIOV vfs. > >> But this patch follows existing sriov vf get code and > >> accomodate filters for all VF's in a PF. > >> And for the SRIOV case I have only tested the fact that the VF > >> arguments are getting delivered to rtnetlink correctly. The rest of > >> the code follows existing sriov vf handling code so it should work > >> just fine] > >> - Fixed all op and netlink attribute names to start with IFLA_RX_FILTER > >> - Changed macvlan filter ops to call corresponding lowerdev op if > lowerdev > >> supports it for passthru mode. Else it falls back on macvlan handling > >> the > >> filters locally as in v1 and v2 > >> > >> v1 -> v2 > >> - Instead of TUNSETTXFILTER introduced rtnetlink interface for the same > >> > > > > [snip...] > > > >> > >> This patch series implements the following > >> 01/6 rtnetlink: Netlink interface for setting MAC and VLAN filters > >> 02/6 netdev: Add netdev_ops to set and get MAC/VLAN rx filters > >> 03/6 rtnetlink: Add support to set MAC/VLAN filters > >> 04/6 rtnetlink: Add support to get MAC/VLAN filters > >> 05/6 macvlan: Add support to set MAC/VLAN filter netdev ops > >> 06/6 macvlan: Add support to get MAC/VLAN filter netdev ops > >> > >> Please comment. Thanks. > > > > After some preliminary review this looks pretty good to me in so far as > adding > > the necessary hooks to do what I need to do. I appreciate your effort > on > > this. > > > > I'm sort of a hands-on type of person so I need to apply this patch to a > > private git tree and then take it for a test drive (so to speak). If I have > > further comments I'll get back to you. > > > Sounds good. > > > Did you have any plans for modifying any user space tools such as 'ip' to > > use > > this interface? > > > > Yes, I have an iproute2 sample patch for setting and displaying the filters > which I have been using to test this interface. I can send the patch to you > after some cleanup if you think it will be useful for you to try out this > interface. > > Thanks Greg. Yes, please do. Thanks, - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address filtering support for passthru mode
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Roopa Prabhu
> Sent: Friday, October 28, 2011 7:34 PM
> To: net...@vger.kernel.org
> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; kvm@vger.kernel.org;
> a...@arndb.de; m...@redhat.com; da...@davemloft.net; Rose, Gregory V;
> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com;
> eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com
> Subject: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address filtering
> support for passthru mode
>
> v2 -> v3
> - Moved set and get filter ops from rtnl_link_ops to netdev_ops
> - Support for SRIOV VFs.
> [Note: The get filters msg might get too big for SRIOV vfs.
> But this patch follows existing sriov vf get code and
> accomodate filters for all VF's in a PF.
> And for the SRIOV case I have only tested the fact that the VF
> arguments are getting delivered to rtnetlink correctly. The rest of
> the code follows existing sriov vf handling code so it should work
> just fine]
> - Fixed all op and netlink attribute names to start with IFLA_RX_FILTER
> - Changed macvlan filter ops to call corresponding lowerdev op if lowerdev
> supports it for passthru mode. Else it falls back on macvlan handling
> the
> filters locally as in v1 and v2
>
> v1 -> v2
> - Instead of TUNSETTXFILTER introduced rtnetlink interface for the same
>
[snip...]
>
> This patch series implements the following
> 01/6 rtnetlink: Netlink interface for setting MAC and VLAN filters
> 02/6 netdev: Add netdev_ops to set and get MAC/VLAN rx filters
> 03/6 rtnetlink: Add support to set MAC/VLAN filters
> 04/6 rtnetlink: Add support to get MAC/VLAN filters
> 05/6 macvlan: Add support to set MAC/VLAN filter netdev ops
> 06/6 macvlan: Add support to get MAC/VLAN filter netdev ops
>
> Please comment. Thanks.
After some preliminary review this looks pretty good to me in so far as adding
the necessary hooks to do what I need to do. I appreciate your effort on this.
I'm sort of a hands-on type of person so I need to apply this patch to a
private git tree and then take it for a test drive (so to speak). If I have
further comments I'll get back to you.
Did you have any plans for modifying any user space tools such as 'ip' to use
this interface?
- Greg
>
> Signed-off-by: Roopa Prabhu
> Signed-off-by: Christian Benvenuti
> Signed-off-by: David Wang
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
> -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, October 25, 2011 8:46 AM > To: Roopa Prabhu > Cc: net...@vger.kernel.org; s...@us.ibm.com; dragos.tatu...@gmail.com; > a...@arndb.de; kvm@vger.kernel.org; da...@davemloft.net; > mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com; Rose, Gregory V > Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address > filtering support for passthru mode > > On Mon, Oct 24, 2011 at 11:15:05AM -0700, Roopa Prabhu wrote: > > >> ... And also I dont know of any hw > > >> that provides an interface to set hw filters on a per queue basis. > > > > > > VMDq hardware would support this, no? > > > > > Am not really sure. This patch uses netdev to pass filters to hw. And I > > don't see any netdev infrastructure that would support per queue > filters. > > Sure. I was only saying that as far as I understand, > VMDq hardware does support this functionality. > Right, Greg? In the case of Intel HW yes. I'll refrain from speaking for other HW vendors although I'm guessing it would be true in their cases also. YMMV, caveat emptor, etc. etc. - Greg > > -- > MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Roopa Prabhu > Sent: Monday, October 24, 2011 11:15 AM > To: Michael S. Tsirkin > Cc: net...@vger.kernel.org; s...@us.ibm.com; dragos.tatu...@gmail.com; > a...@arndb.de; kvm@vger.kernel.org; da...@davemloft.net; > mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com; Rose, Gregory V > Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address > filtering support for passthru mode > > On 10/23/11 10:47 PM, "Michael S. Tsirkin" wrote: > > >> AFAIK, there is no netdev interface to install per queue hw > >> filters for a multi queue interface. And also I dont know of any hw > >> that provides an interface to set hw filters on a per queue basis. > > > > VMDq hardware would support this, no? > > > Am not really sure. This patch uses netdev to pass filters to hw. And I > don't see any netdev infrastructure that would support per queue filters. > Maybe Greg (CC'ed) or anyone else from Intel can answer this. > Greg, michael had brought up this question during first version of these > patches as well. Will be nice to get the VMDq requirements for propagating > guest filters to hw clarified. Do you see any special VMDq nic requirement > we can cover in this patch. This is for VMDq queues directly connected to > guest nics. Thanks. So far as I know there is no support for VMDq in the Linux kernel and while I know some folks have been working on it I can't really speak to that work or their plans. Much would depend on the implementation. For now it makes sense to me to get support for multiple MAC and VLAN filters per virtual function (or virtual nic) and it seems to me you're going in the right direction for this. We'll have a look at your next set of patches and take it from there. - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Rose, Gregory V > Sent: Thursday, October 20, 2011 1:44 PM > To: Roopa Prabhu; net...@vger.kernel.org > Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de; > kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net; > mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com > Subject: RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address > filtering support for passthru mode > > > -Original Message- > > From: Roopa Prabhu [mailto:ropra...@cisco.com] > > Sent: Wednesday, October 19, 2011 3:30 PM > > To: Rose, Gregory V; net...@vger.kernel.org > > Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de; > > kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net; > > mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > > eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com > > Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address > > filtering support for passthru mode > > > > > > > > > > On 10/19/11 2:06 PM, "Rose, Gregory V" wrote: > > > > >> -Original Message- > > >> From: netdev-ow...@vger.kernel.org [mailto:netdev- > > ow...@vger.kernel.org] > > >> On Behalf Of Roopa Prabhu > > >> Sent: Tuesday, October 18, 2011 11:26 PM > > >> To: net...@vger.kernel.org > > >> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de; > > >> kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net; > > >> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > > >> eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com > > >> Subject: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address > filtering > > >> support for passthru mode > > >> > > > > > > [snip...] > > > > > >> > > >> > > >> Note: The choice of rtnl_link_ops was because I saw the use case for > > >> this in virtual devices that need to do filtering in sw like macvlan > > >> and tun. Hw devices usually have filtering in hw with netdev->uc and > > >> mc lists to indicate active filters. But I can move from > rtnl_link_ops > > >> to netdev_ops if that is the preferred way to go and if there is a > > >> need to support this interface on all kinds of interfaces. > > >> Please suggest. > > > > > > I'm still digesting the rest of the RFC patches but I did want to > > quickly jump > > > in and push for adding this support in netdev_ops. I would like to > see > > these > > > features available in more devices than just macvtap and macvlan. I > can > > > conceive > > > of use cases for multiple HW MAC and VLAN filters for a VF device that > > isn't > > > owned by a macvlan/macvtap interface and only has netdev_ops support. > > In this > > > case it would be necessary to program the filters directly to the VF > > device > > > interface or PF interface (or lowerdev as you refer to it) instead of > > going > > > through macvlan/macvtap. > > > > > > This work dovetails nicely with some work I've been doing and I'd be > > very > > > interested > > > in helping move this forward if we could work out the details that > would > > allow > > > support > > > of the features we (and the community) require. > > > > Great. Thanks. I will definitely be interested to get this patch working > > for > > any other use case you have. > > > > Moving the ops to netdev should be trivial. You probably want the ops to > > work on the VF via the PF, like the existing ndo_set_vf_mac etc. > > That is correct, so we would need to add some way to pass the VF number to > the op. > In addition, there are use cases for multiple MAC address filters for the > Physical > Function (PF) so we would like to be able to identify to the netdev op > that it is > supposed to perform the action on the PF filters instead of a VF. > > An example of this would be when an administrator has created some number of > VFs > for a given PF but is also running the PF in bridged (i.e. promiscuous)mode so > that it can support purely SW emulated network connections in some VMs that > have > low network latency and bandwidth requirements while reserving the VFs for > VMs that ^^^ That should be "no", not low... - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
> -Original Message- > From: Roopa Prabhu [mailto:ropra...@cisco.com] > Sent: Wednesday, October 19, 2011 3:30 PM > To: Rose, Gregory V; net...@vger.kernel.org > Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de; > kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net; > mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com > Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address > filtering support for passthru mode > > > > > On 10/19/11 2:06 PM, "Rose, Gregory V" wrote: > > >> -Original Message- > >> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] > >> On Behalf Of Roopa Prabhu > >> Sent: Tuesday, October 18, 2011 11:26 PM > >> To: net...@vger.kernel.org > >> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de; > >> kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net; > >> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com; > >> eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com > >> Subject: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering > >> support for passthru mode > >> > > > > [snip...] > > > >> > >> > >> Note: The choice of rtnl_link_ops was because I saw the use case for > >> this in virtual devices that need to do filtering in sw like macvlan > >> and tun. Hw devices usually have filtering in hw with netdev->uc and > >> mc lists to indicate active filters. But I can move from rtnl_link_ops > >> to netdev_ops if that is the preferred way to go and if there is a > >> need to support this interface on all kinds of interfaces. > >> Please suggest. > > > > I'm still digesting the rest of the RFC patches but I did want to > quickly jump > > in and push for adding this support in netdev_ops. I would like to see > these > > features available in more devices than just macvtap and macvlan. I can > > conceive > > of use cases for multiple HW MAC and VLAN filters for a VF device that > isn't > > owned by a macvlan/macvtap interface and only has netdev_ops support. > In this > > case it would be necessary to program the filters directly to the VF > device > > interface or PF interface (or lowerdev as you refer to it) instead of > going > > through macvlan/macvtap. > > > > This work dovetails nicely with some work I've been doing and I'd be > very > > interested > > in helping move this forward if we could work out the details that would > allow > > support > > of the features we (and the community) require. > > Great. Thanks. I will definitely be interested to get this patch working > for > any other use case you have. > > Moving the ops to netdev should be trivial. You probably want the ops to > work on the VF via the PF, like the existing ndo_set_vf_mac etc. That is correct, so we would need to add some way to pass the VF number to the op. In addition, there are use cases for multiple MAC address filters for the Physical Function (PF) so we would like to be able to identify to the netdev op that it is supposed to perform the action on the PF filters instead of a VF. An example of this would be when an administrator has created some number of VFs for a given PF but is also running the PF in bridged (i.e. promiscuous) mode so that it can support purely SW emulated network connections in some VMs that have low network latency and bandwidth requirements while reserving the VFs for VMs that require the low latency, high throughput that directly assigned VFs can provide. In this case an emulated SW interface in a VM is unable to properly communicate with VFs on the same PF because the emulated SW interface's MAC address isn't programmed into the HW filters on the PF. If we could use this op to program the MAC address and VLAN filters of the emulated SW interfaces into the PF HW a VF could then properly communicate across the NIC's internal VEB to the emulated SW interfaces. > Yes, lets work out the details and I can move this to netdev->ops. Let me > know. I think essentially if you could add some parameter to the ops to specify whether it is addressing a VF or the PF and then if it is a VF further specify the VF number we would be very close to addressing the requirements of many valuable use cases in addition to the ones you have identified in your RFC. Does that sound reasonable? Thanks, - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Roopa Prabhu
> Sent: Tuesday, October 18, 2011 11:26 PM
> To: net...@vger.kernel.org
> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de;
> kvm@vger.kernel.org; m...@redhat.com; da...@davemloft.net;
> mc...@broadcom.com; dwa...@cisco.com; shemmin...@vyatta.com;
> eric.duma...@gmail.com; ka...@trash.net; be...@cisco.com
> Subject: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering
> support for passthru mode
>
[snip...]
>
>
> Note: The choice of rtnl_link_ops was because I saw the use case for
> this in virtual devices that need to do filtering in sw like macvlan
> and tun. Hw devices usually have filtering in hw with netdev->uc and
> mc lists to indicate active filters. But I can move from rtnl_link_ops
> to netdev_ops if that is the preferred way to go and if there is a
> need to support this interface on all kinds of interfaces.
> Please suggest.
I'm still digesting the rest of the RFC patches but I did want to quickly jump
in and push for adding this support in netdev_ops. I would like to see these
features available in more devices than just macvtap and macvlan. I can
conceive
of use cases for multiple HW MAC and VLAN filters for a VF device that isn't
owned by a macvlan/macvtap interface and only has netdev_ops support. In this
case it would be necessary to program the filters directly to the VF device
interface or PF interface (or lowerdev as you refer to it) instead of going
through macvlan/macvtap.
This work dovetails nicely with some work I've been doing and I'd be very
interested
in helping move this forward if we could work out the details that would allow
support
of the features we (and the community) require.
- Greg Rose
LAN Access Division
Intel Corp.
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
RE: [PATCH net-next] ixgbe: make macvlan on PF working when SRIOV is enabled
>-Original Message- >From: Shirley Ma [mailto:mashi...@us.ibm.com] >Sent: Tuesday, May 25, 2010 10:16 AM >To: Kirsher, Jeffrey T >Cc: Rose, Gregory V; da...@davemloft.net; kvm@vger.kernel.org; >net...@vger.kernel.org; e1000-de...@lists.sourceforge.net >Subject: Re: [PATCH net-next] ixgbe: make macvlan on PF working when >SRIOV is enabled > >To produce this problem: > >1. modprobe ixgbe max_vfs=2 > eth4 is PF, eth5 is VF >2. ip link set eth4 up >3. ip link add link eth4 address 54:52:00:35:e3:20 macvlan2 type macvlan >4. ip addr add 192.168.7.74/24 dev macvlan2 >5. ping macvlan2 from remote host, works >6. ip link set eth5 up >7. ping macvlan2 from remote host failed. > >Based on my understanding, the problem is: >1. PF set_rar use rar index is 0, and vmdq index is adapter->num_vfs, >2. when macvlan2 is created, rar index is based rar_used_count, which >would be 1. >3. later when VF is up, the rar index is vf+1, and vmdq index is vf, so >VF0 will overwrite macvlan2 rar entry. > >The fix here: >1. make sure PF uses vmdq index = adapter->num_vfs during >initialization, reset. >2. reserve rar index for all VFs from 1 to num_vfs + 1. > > >Please let me know whether my understanding is correct or not. Yes, that appears to be correct. We'll test your patch but I think you're on the right track. - Greg
RE: ixgbe: macvlan on PF/VF when SRIOV is enabled
>-Original Message- >From: Shirley Ma [mailto:mashi...@us.ibm.com] >Sent: Tuesday, May 25, 2010 9:51 AM >To: Rose, Gregory V >Cc: Kirsher, Jeffrey T; da...@davemloft.net; kvm@vger.kernel.org; >net...@vger.kernel.org; e1000-de...@lists.sourceforge.net >Subject: RE: ixgbe: macvlan on PF/VF when SRIOV is enabled > >On Tue, 2010-05-25 at 08:57 -0700, Rose, Gregory V wrote: >> Just use ifconfig and vconfig utilities to set the MAC and VLAN for >> each VF. There shouldn't be any need for secondary addresses because >> they're not like physical devices where each VF has a pre-programmed >> HW MAC address. The initial MAC address of each VF is generated on >> the fly during the PF driver initialization. You can change it as you >> see fit and then put the VF on a VLAN using vconfig. After you do >> that you have a macvlan filter for that VF. > >I run macvlan test not vlan. macvlan is used to give a second MAC >address to a network adapter and see it as a new device at the higher >levels. The command is used as follow: > >ip link add link eth4 address 54:52:00:35:e3:20 macvlan2 type macvlan > >It will create an interface name macvlan2 with above MAC address. In >kernel, netdev eth4 maintains this secondary address. Right, so what I'm saying is that if you load the VF driver it will create and interface for each VF you've created. You can assign a MAC and VLAN to that interface and will get essentially the same behavior. - Greg
RE: ixgbe: macvlan on PF/VF when SRIOV is enabled
>-Original Message- >From: Shirley Ma [mailto:mashi...@us.ibm.com] >Sent: Tuesday, May 25, 2010 2:37 AM >To: Rose, Gregory V >Cc: Kirsher, Jeffrey T; da...@davemloft.net; kvm@vger.kernel.org; >net...@vger.kernel.org; e1000-de...@lists.sourceforge.net >Subject: RE: ixgbe: macvlan on PF/VF when SRIOV is enabled > >On Mon, 2010-05-24 at 10:54 -0700, Rose, Gregory V wrote: >> We look forward to it and will be happy to provide feedback. >I have submitted the patch to make macvlan on PF works when SRIOV is >enabled. > >> One thing you can do is allocate VFs and then load the VF driver in >> your host domain and then assign each of them a macvlan filter. You'd >> get a similar effect. > >That's I am trying to make it work for macvlan on VFs in host domain. I >need to add VF secondary addresses in address filter, right? Just use ifconfig and vconfig utilities to set the MAC and VLAN for each VF. There shouldn't be any need for secondary addresses because they're not like physical devices where each VF has a pre-programmed HW MAC address. The initial MAC address of each VF is generated on the fly during the PF driver initialization. You can change it as you see fit and then put the VF on a VLAN using vconfig. After you do that you have a macvlan filter for that VF. > >Do you have any aggregation performance comparison between multiple >macvlans on PF and single macvlan per VF in host domain? No, we haven't done any performance testing of that particular sort but I imagine you should be able to get close to line rates using multiple VFs with a single macvlan filter for each. Regards, - Greg
RE: ixgbe: macvlan on PF/VF when SRIOV is enabled
>-Original Message- >From: Shirley Ma [mailto:mashi...@us.ibm.com] >Sent: Monday, May 24, 2010 10:09 AM >To: Rose, Gregory V >Cc: Kirsher, Jeffrey T; da...@davemloft.net; kvm@vger.kernel.org; >net...@vger.kernel.org; e1000-de...@lists.sourceforge.net >Subject: RE: ixgbe: macvlan on PF/VF when SRIOV is enabled > >Hello Greg, > >Thanks for your prompt response. > >On Sat, 2010-05-22 at 10:53 -0700, Rose, Gregory V wrote: >> As of 2.6.34 the ixgbe driver does not support multiple queues for >> macvlan. >> Support for multiple queues for macvlan will come in a subsequent >> release. > >When it might happen? Support for multiple queues in the PF driver is in the planning stage right now. Hopefully we'll get it in sooner rather than later but I can't give any solid dates for it. I will double check my test to see whether macvlan >was multiple queue or not. Ah, so you just want to set multiple macvlan filters for the PF driver but aren't concerned about directing the traffic to different queues? We haven't tested that in SR-IOV modes of operation but we can have a look at it. Then submitting my experimental patch for >review. We look forward to it and will be happy to provide feedback. > >> The VF driver does not support macvlan. Future releases may but there >> are no immediate plans to support it. > >When it might be support in future. For performance reason, we are >interested in macvlan + VF for multiples VMs. There is a resource contention issue in this case. There are 128 MAC filters available. When VFs are allocated each will use a MAC filter entry. In the case where the maximum number of VFs are allocated (63 in this case) there aren't a whole lot of MAC filters left over to spread across that many VFs. Our view has been that it wouldn't be that much added value to support macvlan in the VFs but if there is a good case for it we'll consider it. One thing you can do is allocate VFs and then load the VF driver in your host domain and then assign each of them a macvlan filter. You'd get a similar effect. > >One more question here: Does VF support promiscuous mode? I don't see >the flag in ixgbevf driver. No, there is no per-VF support for promiscuous mode in the HW as such, however you could set the unicast hash table array to all ones and then set the VFs you want to be in promiscuous mode to accept untagged packets via the VM filtering and offload register at offset 0F000h. However, re-provisioning the UTA for this purpose would preclude using it for the designed purpose. I suggest that you pick up a copy of the developer's manual for the 82599 at the Intel developer's site. http://developer.intel.com/products/ethernet/index.htm?iid=nc+ethernet#s1=all&s2=82576EB&s3=all - Greg
RE: ixgbe: macvlan on PF/VF when SRIOV is enabled
>-Original Message- >From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] >On Behalf Of Shirley Ma >Sent: Friday, May 21, 2010 1:31 PM >To: Kirsher, Jeffrey T >Cc: da...@davemloft.net; kvm@vger.kernel.org; net...@vger.kernel.org; >e1000-de...@lists.sourceforge.net >Subject: ixgbe: macvlan on PF/VF when SRIOV is enabled > >Hello Jeff, > >macvlan doesn't work on PF when SRIOV is enabled. Creating macvlan has >been successful, but ping (icmp request) goes to VF interface not >PF/macvlan even arp entry is correct. I patched ixgbe driver, and >macvlan/PF has worked with the patch. But I am not sure whether it is >right since I don't have the HW spec. What I did for ixgbe driver was: > >1. PF's rar index is 0, VMDQ index is adatper->num_vfs; >2. VF's rar is based on rar_used_count and mc_addr_in_rar_count, VMDQ >index is ; >3. PF's secondary addresses is PF's rar index + i, VMDQ index is >adapter->num_vfs. As of 2.6.34 the ixgbe driver does not support multiple queues for macvlan. Support for multiple queues for macvlan will come in a subsequent release. > > >Before I submit the patch, I want to understand the right index >assignment for both rar index and VMDQ index, when SRIOV enabled: >1. VMDQ index for PF is adapter->num_vfs, or 0? rar index is 0? >2. PF's secondary address rar index is based on >rar_used_count/mc_addr_in_rar_count? >2. VF's VPDQ index is based on vf number? >3. VF's rar index is vf + 1, or should be based on rar_used_count? > >I am also working on macvlan on VF. The question here is whether macvlan >on VF should work or not? Looks like ixgbevf secondary addresses are not >in receiver address filter, so macvlan on VF doesn't work. The VF driver does not support macvlan. Future releases may but there are no immediate plans to support it. - Greg Rose Intel Corp. Lan Access Division
RE: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support
Jesse Barnes wrote: > > Hm, that's not the answer I was hoping for. :) (Was looking for, > "Yeah we just need this bits queued and we'll send an update for > e1000 right away." :) > > I really don't want the SR-IOV stuff to sit out another merge cycle > though... Arg. We will have drivers that support these API's posted to the lists within two or three days. These drivers are RFC only and not to be pushed upstream. More non-Xen testing needs to happen with the 82576 HW. - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support
Jeremy Fitzhardinge wrote: > Which dom0 kernel are you using? Is it based on my pvops-based dom0 work? The kernel I'm currently using is an ad-hoc patchwork of changes to the 2.6.18 Xen Dom0 kernel that was available back in August. The folks from OTC in Intel (Zhao Yu and his team) would be able to provide you more background on it as they did the work to enable MSI-X, SR-IOV and VT-d in that kernel so that my drivers would function. I don't see Zhao Yu on the distro list for this email so I'll add him. - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support
-Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] On Wednesday, December 17, 2008 8:44 am Rose, Gregory V wrote: > As noted in the attached email to the netdev list, we (e1000_devel) will > support the API. Do you think you'll have those changes ready for 2.6.29? Would merging core SR-IOV support now make that any more likely? >>>>>>>>> I'm not sure about readiness for 2.6.29. I can tell you that as soon as I get a Xen Dom0 kernel with these API's included it will take me less than a day to convert over to them from the current drivers I have that are using an older API from back in August. The drivers are mostly functional, they have a few bugs. I could do some quick regression testing to make sure that the API changes haven't broken anything and then some bug fixes to get everything ready for release. Maybe two or three weeks for the major bugs. I'll be out over the Christmas holidays so that puts us into middle or late January if I got the Xen Dom0 kernel today. That seems unlikely but it gives you an idea of the time required. - Greg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support
As noted in the attached email to the netdev list, we (e1000_devel) will support the API. - Greg Rose -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Greg KH Sent: Tuesday, December 16, 2008 10:06 PM To: Jike Song Cc: Jesse Barnes; Zhao, Yu; linux-...@vger.kernel.org; achi...@hp.com; bjorn.helg...@hp.com; grund...@parisc-linux.org; mi...@elte.hu; matt...@wil.cx; randy.dun...@oracle.com; rdre...@cisco.com; ho...@verge.net.au; ying...@kernel.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org; virtualizat...@lists.linux-foundation.org Subject: Re: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support On Wed, Dec 17, 2008 at 10:37:54AM +0800, Jike Song wrote: > Jesse Barnes wrote: > > Given a respin of 10-13 I think it's reasonable to merge this into 2.6.29, > > but > > I'd be much happier about it if we got some driver code along with it, so > > as > > not to have an unused interface sitting around for who knows how many > > releases. Is that reasonable? Do you know if any of the corresponding > > PF/VF > > driver bits are ready yet? > > Hi Jesse, > > Yu Zhao has posted a patch set with subject "SR-IOV driver example" > at November 26, which illustrated the usage of SR-IOV API in Intel 82576 VF/PF > drivers;-) Yes, but that driver was soundly rejected by the network driver maintainers, so I wouldn't go around showing that as your primary example of how to use this interface :) The point is valid, I don't think these apis should go into the tree without a driver or some other code using them. Otherwise they make no sense at all to have in-tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- Begin Message --- On Tue, Dec 2, 2008 at 1:27 AM, Yu Zhao wrote: > SR-IOV drivers of Intel 82576 NIC are available. There are two parts > of the drivers: Physical Function driver and Virtual Function driver. > The PF driver is based on the IGB driver and is used to control PF to > allocate hardware specific resources and interface with the SR-IOV core. > The VF driver is a new NIC driver that is same as the traditional PCI > device driver. It works in both the host and the guest (Xen and KVM) > environment. > > These two drivers are testing versions and they are *only* intended to > show how to use SR-IOV API. > > Intel 82576 NIC specification can be found at: > http://download.intel.com/design/network/datashts/82576_Datasheet_v2p1.pdf > > [SR-IOV driver example 0/3 resend] introduction > [SR-IOV driver example 1/3 resend] PF driver: hardware specific operations > [SR-IOV driver example 2/3 resend] PF driver: integrate with SR-IOV core > [SR-IOV driver example 3/3 resend] VF driver: an independent PCI NIC driver > -- > First of all, we (e1000-devel) do support the SR-IOV API. With that said, NAK on the driver changes. We were not involved in these changes and are currently working on a version of the drivers that will make them acceptable for kernel inclusion. -- Cheers, Jeff --- End Message ---
RE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
This driver must work for all kernels, whether they have SRIOV support or not. Presumably the #ifdef CONFIG_PCI_IOV would be stripped for a kernel driver where the kernel configures SR-IOV support. I'll let John Ronciak respond on the issue of upstream review. - Greg -Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 10:39 AM To: Rose, Gregory V Cc: Zhao, Yu; Dong, Eddie; kvm@vger.kernel.org; Barnes, Jesse; Ronciak, John; Nakajima, Jun; Yu, Wilfred; Li, Xin B; Li, Susie Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support On Fri, Nov 14, 2008 at 09:48:15AM -0800, Rose, Gregory V wrote: > It's not upstream yet. However, if you grep through for > CONFIG_PCI_IOV you'll see all the relevant code in those sections. Wouldn't it make more sense for the IOV code to be reworked to not require #ifdefs in a driver? There seems to be a bit too much #ifdef code in this driver right now :( What is the status of submitting it upstream and getting netdev review of it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
It's not upstream yet. However, if you grep through for CONFIG_PCI_IOV you'll see all the relevant code in those sections. - Greg (Rose that is) -Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 9:40 AM To: Zhao, Yu Cc: Rose, Gregory V; Dong, Eddie; kvm@vger.kernel.org; Barnes, Jesse; Ronciak, John; Nakajima, Jun; Yu, Wilfred; Li, Xin B; Li, Susie Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support On Fri, Nov 14, 2008 at 03:56:19PM +0800, Zhao, Yu wrote: > Hi Greg KH, > > I updated PF driver to use latest SR-IOV API in the patch set v6, and > attached it. Please take a look and please let us know if you have any > comments. Is this driver already upstream? If so, can you just send the diff that adds the SR-IOV changes to it? Otherwise it's a bit hard to just pick out those pieces, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
