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#174; 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, I'm understanding you saying that VM4 or VM4 sending a packet to VM1 goes in to VEB, out PF, and into linux bridging code, rigth? At which point the PF is in promiscuous mode (btw, same does not work if bridge is attached to VF, at least for some VFs, due to lack of promiscuous mode). Packets sent from a guest with a VF to the address of another guest with a VF need to be forwarded similarly, but the driver should be able to infer that from (3). Right, and that works currently for the case where both guests are like VM4, they directly own the VF via PCI device assignement. But for VM4 to talk to VM5, VF3 is not in promiscuous mode and has a different MAC address than VM5's vNIC. If the embedded bridge does not learn, and nobody programmed it to fwd frames for VM5 via VF3... I believe this is what Roopa's patch will allow. The question now is whether there's a better way to handle this? In my mind, we'd model the NIC's embedded bridge as, well
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_SPOOFCHK). In 802.1Qbh case the port profile has a knob to
enable/disable anti spoof check. Lowerdevice
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 ropra...@cisco.com
Signed-off-by: Christian Benvenuti be...@cisco.com
Signed-off-by: David Wang dwa...@cisco.com
--
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/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 gregory.v.r...@intel.com 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/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 m...@redhat.com 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: 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 gregory.v.r...@intel.com 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 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 gregory.v.r...@intel.com 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: 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: 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=alls2=82576EBs3=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
-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 ---BeginMessage--- On Tue, Dec 2, 2008 at 1:27 AM, Yu Zhao yu.z...@intel.com 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/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/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
