RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
On Thu, 2011-10-20 at 13:43 -0700, Rose, Gregory V wrote: -Original Message- From: Roopa Prabhu [mailto:ropra...@cisco.com] [...] 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. [...] This would also be good for Solarflare's VF plugin architecture. The VF driver works as a plugin for virtio or xen_netfront and can refuse packets that need to be bridged to another (physically) local address. The PF driver has to tell VFs what the local addresses are and currently relies on some custom scripting to know about those extra addresses. (No, none of that is upstream - I'm preparing for that now.) Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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
On Tue, 2011-10-25 at 08:59 -0700, Rose, Gregory V wrote: -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. Current Solarflare hardware supports: - RX MAC address filters for queue selection (steering), which can be combined with RSS (flow hashing) - TX MAC address filters to prevent spoofing Multiple filters can be associated with a single queue. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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
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/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? -- 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: 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
On 10/23/11 10:47 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 18, 2011 at 11:25:54PM -0700, Roopa Prabhu wrote:
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.
Looks sane to me. Some minor comments below.
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 drivers also enforce limits
on the number of address registrations allowed.
- Support for multiqueue devices: Enable filtering on individual queues (?):
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.
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
On Tue, Oct 18, 2011 at 11:25:54PM -0700, Roopa Prabhu wrote:
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.
Looks sane to me. Some minor comments below.
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 drivers also enforce limits
on the number of address registrations allowed.
- Support for multiqueue devices: Enable filtering on individual queues (?):
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
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
On 10/20/11 1:43 PM, Rose, Gregory V gregory.v.r...@intel.com wrote: -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 for the details Greg. Sounds good. I will change it to provide netdev ops with a vf argument and respin. Thanks, Roopa -- 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: [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. Yes, lets work out the details and I can move this to netdev-ops. Let me know. Thanks, Roopa -- 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
