[net-next PATCH v0 0/5] Series short description

[net-next PATCH v0 0/5] Series short description

[John Fastabend]

This series is a follow up to this thread:

http://www.spinics.net/lists/netdev/msg191360.html

This adds two NTF_XXX bits to signal if the PF_BRIDGE
netlink command should be parsed by the embedded bridge
or the SW bridge. The insight here is the SW bridge is
always the master device (NTF_MASTER) and the embedded
bridge is the lower device (NTF_LOWERDEV). Without either
flag set the command is parsed by the SW bridge to support
existing tooling.

To make this work correctly I added three new ndo ops

	ndo_fdb_add
	ndo_fdb_del
	ndo_fdb_dump

to add, delete, and dump FDB entries. These operations
can be used by drivers to program embedded nics or by
software bridges. We have at least three SW bridge now
net/bridge, openvswitch, and macvlan. And three variants
of embedded bridges SR-IOV devices, multi-function devices
and Distributed Switch Architecture (DSA).

I think at least in this case adding netdevice ops is
the cleanest way to implement this. I thought about
notifier hooks and other methods but this seems to be
the simplest.

I've tested these three scenarios, embedded bridge only,
sw bridge only, and embedded bridge and SW bridge. These
are working on the Intel 82599 devices with this patch
series. I am also working on a patch for the macvlan
drivers. I'll submit that as an RFC shortly so far I
only have the passthru mode wired up.

Thanks to Stephen, Ben, and Jamal for bearing with me
and the feedback on the last round of patches.

As always any comments/feedback appreciated!

---

John Fastabend (5):
      ixgbe: allow RAR table to be updated in promisc mode
      ixgbe: enable FDB netdevice ops
      net: add fdb generic dump routine
      net: addr_list: add exclusive dev_uc_add
      net: add generic PF_BRIDGE:RTM_XXX FDB hooks


 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   80 +++++++++-
 include/linux/neighbour.h                     |    3 
 include/linux/netdevice.h                     |   27 +++
 include/linux/rtnetlink.h                     |    4 +
 net/bridge/br_device.c                        |    3 
 net/bridge/br_fdb.c                           |  128 ++++------------
 net/bridge/br_netlink.c                       |   12 --
 net/bridge/br_private.h                       |   15 ++
 net/core/dev_addr_lists.c                     |   19 ++
 net/core/rtnetlink.c                          |  194 +++++++++++++++++++++++++
 10 files changed, 363 insertions(+), 122 deletions(-)

-- 
Signature

[net-next PATCH v0 2/5] net: addr_list: add exclusive dev_uc_add

[John Fastabend]

This adds a dev_uc_add_excl() call similar to the original
dev_uc_add() except it sets the global bit. With this
change the reference count will not be bumped and -EEXIST
will be returned if a duplicate address exists.

This is useful for drivers that support SR-IOV and want
to manage the unicast lists.

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---

 include/linux/netdevice.h |    1 +
 net/core/dev_addr_lists.c |   19 +++++++++++++++++++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4208901..5e43cec 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2571,6 +2571,7 @@ extern int dev_addr_init(struct net_device *dev);
 
 /* Functions used for unicast addresses handling */
 extern int dev_uc_add(struct net_device *dev, unsigned char *addr);
+extern int dev_uc_add_excl(struct net_device *dev, unsigned char *addr);
 extern int dev_uc_del(struct net_device *dev, unsigned char *addr);
 extern int dev_uc_sync(struct net_device *to, struct net_device *from);
 extern void dev_uc_unsync(struct net_device *to, struct net_device *from);
diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index 29c07fe..c7d27ad 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -377,6 +377,25 @@ EXPORT_SYMBOL(dev_addr_del_multiple);
  */
 
 /**
+ *	dev_uc_add_excl - Add a global secondary unicast address
+ *	@dev: device
+ *	@addr: address to add
+ */
+int dev_uc_add_excl(struct net_device *dev, unsigned char *addr)
+{
+	int err;
+
+	netif_addr_lock_bh(dev);
+	err = __hw_addr_add_ex(&dev->uc, addr, dev->addr_len,
+			       NETDEV_HW_ADDR_T_UNICAST, true);
+	if (!err)
+		__dev_set_rx_mode(dev);
+	netif_addr_unlock_bh(dev);
+	return err;
+}
+EXPORT_SYMBOL(dev_uc_add_excl);
+
+/**
  *	dev_uc_add - Add a secondary unicast address
  *	@dev: device
  *	@addr: address to add

Re: [net-next PATCH v0 2/5] net: addr_list: add exclusive dev_uc_add

[Roopa Prabhu]

On 3/18/12 11:51 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:

> This adds a dev_uc_add_excl() call similar to the original
> dev_uc_add() except it sets the global bit. With this
> change the reference count will not be bumped and -EEXIST
> will be returned if a duplicate address exists.
> 
> This is useful for drivers that support SR-IOV and want
> to manage the unicast lists.
> 
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> 
>  include/linux/netdevice.h |    1 +
>  net/core/dev_addr_lists.c |   19 +++++++++++++++++++
>  2 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 4208901..5e43cec 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2571,6 +2571,7 @@ extern int dev_addr_init(struct net_device *dev);
>  
>  /* Functions used for unicast addresses handling */
>  extern int dev_uc_add(struct net_device *dev, unsigned char *addr);
> +extern int dev_uc_add_excl(struct net_device *dev, unsigned char *addr);
>  extern int dev_uc_del(struct net_device *dev, unsigned char *addr);
>  extern int dev_uc_sync(struct net_device *to, struct net_device *from);
>  extern void dev_uc_unsync(struct net_device *to, struct net_device *from);
> diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
> index 29c07fe..c7d27ad 100644
> --- a/net/core/dev_addr_lists.c
> +++ b/net/core/dev_addr_lists.c
> @@ -377,6 +377,25 @@ EXPORT_SYMBOL(dev_addr_del_multiple);
>   */
>  
>  /**
> + * dev_uc_add_excl - Add a global secondary unicast address
> + * @dev: device
> + * @addr: address to add
> + */
> +int dev_uc_add_excl(struct net_device *dev, unsigned char *addr)
> +{
> + int err;
> +
> + netif_addr_lock_bh(dev);
> + err = __hw_addr_add_ex(&dev->uc, addr, dev->addr_len,
> +          NETDEV_HW_ADDR_T_UNICAST, true);
> + if (!err)
> +  __dev_set_rx_mode(dev);
> + netif_addr_unlock_bh(dev);
> + return err;
> +}
> +EXPORT_SYMBOL(dev_uc_add_excl);
> +
> +/**

ACK.
We will need a similar function for multicast as well ?. Macvlan could use
it.

Thanks,
Roopa

[net-next PATCH v0 3/5] net: add fdb generic dump routine

[John Fastabend]

This adds a generic dump routine drivers can call. It
should be sufficient to handle any bridging model that
uses the unicast address list. This should be most SR-IOV
enabled NICs.

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---

 net/core/rtnetlink.c |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 8c3278a..35ee2d6 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2082,6 +2082,62 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
 	return err;
 }
 
+/**
+ * ndo_dflt_fdb_dump: default netdevice operation to dump an FDB table.
+ * @nlh: netlink message header
+ * @dev: netdevice
+ *
+ * Default netdevice operation to dump the existing unicast address list.
+ * Returns zero on success.
+ */
+int ndo_dflt_fdb_dump(struct sk_buff *skb,
+		      struct netlink_callback *cb,
+		      struct net_device *dev,
+		      int idx)
+{
+	struct netdev_hw_addr *ha;
+	struct nlmsghdr *nlh;
+	struct ndmsg *ndm;
+	u32 pid, seq;
+
+	pid = NETLINK_CB(cb->skb).pid;
+	seq = cb->nlh->nlmsg_seq;
+
+	netif_addr_lock_bh(dev);
+	list_for_each_entry(ha, &dev->uc.list, list) {
+		if (idx < cb->args[0])
+			goto skip;
+
+		nlh = nlmsg_put(skb, pid, seq,
+				RTM_NEWNEIGH, sizeof(*ndm), NLM_F_MULTI);
+		if (!nlh)
+			break;
+
+		ndm = nlmsg_data(nlh);
+		ndm->ndm_family  = AF_BRIDGE;
+		ndm->ndm_pad1	 = 0;
+		ndm->ndm_pad2    = 0;
+		ndm->ndm_flags	 = NTF_LOWERDEV;
+		ndm->ndm_type	 = 0;
+		ndm->ndm_ifindex = dev->ifindex;
+		ndm->ndm_state   = NUD_PERMANENT;
+
+		NLA_PUT(skb, NDA_LLADDR, ETH_ALEN, ha->addr);
+
+		nlmsg_end(skb, nlh);
+skip:
+		++idx;
+	}
+	netif_addr_unlock_bh(dev);
+
+	return idx;
+nla_put_failure:
+	netif_addr_unlock_bh(dev);
+	nlmsg_cancel(skb, nlh);
+	return idx;
+}
+EXPORT_SYMBOL(ndo_dflt_fdb_dump);
+
 static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
 {
 	int idx = 0;

Re: [net-next PATCH v0 3/5] net: add fdb generic dump routine

[Roopa Prabhu]

On 3/18/12 11:52 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:

> This adds a generic dump routine drivers can call. It
> should be sufficient to handle any bridging model that
> uses the unicast address list. This should be most SR-IOV
> enabled NICs.
> 
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> 
>  net/core/rtnetlink.c |   56
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 56 insertions(+), 0 deletions(-)
> 
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 8c3278a..35ee2d6 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2082,6 +2082,62 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct
> nlmsghdr *nlh, void *arg)
> return err;
>  }
>  
> +/**
> + * ndo_dflt_fdb_dump: default netdevice operation to dump an FDB table.
> + * @nlh: netlink message header
> + * @dev: netdevice
> + *
> + * Default netdevice operation to dump the existing unicast address list.
> + * Returns zero on success.
> + */
> +int ndo_dflt_fdb_dump(struct sk_buff *skb,
> +        struct netlink_callback *cb,
> +        struct net_device *dev,
> +        int idx)
> +{
> + struct netdev_hw_addr *ha;
> + struct nlmsghdr *nlh;
> + struct ndmsg *ndm;
> + u32 pid, seq;
> +
> + pid = NETLINK_CB(cb->skb).pid;
> + seq = cb->nlh->nlmsg_seq;
> +
> + netif_addr_lock_bh(dev);
> + list_for_each_entry(ha, &dev->uc.list, list) {
> +  if (idx < cb->args[0])
> +   goto skip;

Any reason why its only uc ?. What about mc ?

> +
> +  nlh = nlmsg_put(skb, pid, seq,
> +    RTM_NEWNEIGH, sizeof(*ndm), NLM_F_MULTI);
> +  if (!nlh)
> +   break;
> +
> +  ndm = nlmsg_data(nlh);
> +  ndm->ndm_family  = AF_BRIDGE;
> +  ndm->ndm_pad1  = 0;
> +  ndm->ndm_pad2    = 0;
> +  ndm->ndm_flags  = NTF_LOWERDEV;
> +  ndm->ndm_type  = 0;
> +  ndm->ndm_ifindex = dev->ifindex;
> +  ndm->ndm_state   = NUD_PERMANENT;
> +
> +  NLA_PUT(skb, NDA_LLADDR, ETH_ALEN, ha->addr);
> +
> +  nlmsg_end(skb, nlh);
> +skip:
> +  ++idx;
> + }
> + netif_addr_unlock_bh(dev);
> +
> + return idx;
> +nla_put_failure:
> + netif_addr_unlock_bh(dev);
> + nlmsg_cancel(skb, nlh);
> + return idx;
> +}
> +EXPORT_SYMBOL(ndo_dflt_fdb_dump);
> +
>  static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
>  {
> int idx = 0;
> 

Re: [net-next PATCH v0 3/5] net: add fdb generic dump routine

[John Fastabend]

On 3/25/2012 6:09 AM, Roopa Prabhu wrote:
> 
> 
> 
> On 3/18/12 11:52 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
> 
>> This adds a generic dump routine drivers can call. It
>> should be sufficient to handle any bridging model that
>> uses the unicast address list. This should be most SR-IOV
>> enabled NICs.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>>

[...]

>> +/**
>> + * ndo_dflt_fdb_dump: default netdevice operation to dump an FDB table.
>> + * @nlh: netlink message header
>> + * @dev: netdevice
>> + *
>> + * Default netdevice operation to dump the existing unicast address list.
>> + * Returns zero on success.
>> + */
>> +int ndo_dflt_fdb_dump(struct sk_buff *skb,
>> +        struct netlink_callback *cb,
>> +        struct net_device *dev,
>> +        int idx)
>> +{
>> + struct netdev_hw_addr *ha;
>> + struct nlmsghdr *nlh;
>> + struct ndmsg *ndm;
>> + u32 pid, seq;
>> +
>> + pid = NETLINK_CB(cb->skb).pid;
>> + seq = cb->nlh->nlmsg_seq;
>> +
>> + netif_addr_lock_bh(dev);
>> + list_for_each_entry(ha, &dev->uc.list, list) {
>> +  if (idx < cb->args[0])
>> +   goto skip;
> 
> Any reason why its only uc ?. What about mc ?

Sure this might be useful to know for embedded devices
and likely more useful for the macvlan driver. I'll add
it in the next version.

Thanks,
John

[net-next PATCH v0 4/5] ixgbe: enable FDB netdevice ops

[John Fastabend]

Enable FDB ops on ixgbe when in SR-IOV mode.

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---

 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   59 +++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 1d8f9f8..32adb4f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7586,6 +7586,62 @@ static int ixgbe_set_features(struct net_device *netdev,
 
 }
 
+static int ixgbe_ndo_fdb_add(struct ndmsg *ndm,
+			     struct net_device *dev,
+			     unsigned char *addr,
+			     u16 flags)
+{
+	struct ixgbe_adapter *adapter = netdev_priv(dev);
+	int err = -EOPNOTSUPP;
+
+	if (ndm->ndm_state & NUD_PERMANENT) {
+		pr_info("%s: FDB only supports static addresses\n",
+			ixgbe_driver_name);
+		return -EINVAL;
+	}
+
+	if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
+		err = dev_uc_add_excl(dev, addr);
+
+	/* Only return duplicate errors if NLM_F_EXCL is set */
+	if (err == -EEXIST && !(flags & NLM_F_EXCL))
+		err = 0;
+
+	return err;
+}
+
+static int ixgbe_ndo_fdb_del(struct ndmsg *ndm,
+			     struct net_device *dev,
+			     unsigned char *addr)
+{
+	struct ixgbe_adapter *adapter = netdev_priv(dev);
+	int err = -EOPNOTSUPP;
+
+	if (ndm->ndm_state & NUD_PERMANENT) {
+		pr_info("%s: FDB only supports static addresses\n",
+			ixgbe_driver_name);
+		return -EINVAL;
+	}
+
+	if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
+		err = dev_uc_del(dev, addr);
+
+	return err;
+}
+
+static int ixgbe_ndo_fdb_dump(struct sk_buff *skb,
+			      struct netlink_callback *cb,
+			      struct net_device *dev,
+			      int idx)
+{
+	struct ixgbe_adapter *adapter = netdev_priv(dev);
+
+	if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
+		idx = ndo_dflt_fdb_dump(skb, cb, dev, idx);
+
+	return idx;
+}
+
 static const struct net_device_ops ixgbe_netdev_ops = {
 	.ndo_open		= ixgbe_open,
 	.ndo_stop		= ixgbe_close,
@@ -7620,6 +7676,9 @@ static const struct net_device_ops ixgbe_netdev_ops = {
 #endif /* IXGBE_FCOE */
 	.ndo_set_features = ixgbe_set_features,
 	.ndo_fix_features = ixgbe_fix_features,
+	.ndo_fdb_add		= ixgbe_ndo_fdb_add,
+	.ndo_fdb_del		= ixgbe_ndo_fdb_del,
+	.ndo_fdb_dump		= ixgbe_ndo_fdb_dump,
 };
 
 static void __devinit ixgbe_probe_vf(struct ixgbe_adapter *adapter,

Re: [net-next PATCH v0 4/5] ixgbe: enable FDB netdevice ops

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

On Sun, 2012-03-18 at 23:52 -0700, Fastabend, John R wrote:
> Enable FDB ops on ixgbe when in SR-IOV mode.
> 
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> 
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   59
> +++++++++++++++++++++++++
>  1 files changed, 59 insertions(+), 0 deletions(-) 

Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[net-next PATCH v0 5/5] ixgbe: allow RAR table to be updated in promisc mode

[John Fastabend]

This allows RAR table updates while in promiscuous. With
SR-IOV enabled it is valuable to allow the RAR table to
be updated even when in promisc mode to configure forwarding

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---

 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 32adb4f..d1925b5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3400,16 +3400,17 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
 		}
 		ixgbe_vlan_filter_enable(adapter);
 		hw->addr_ctrl.user_set_promisc = false;
-		/*
-		 * Write addresses to available RAR registers, if there is not
-		 * sufficient space to store all the addresses then enable
-		 * unicast promiscuous mode
-		 */
-		count = ixgbe_write_uc_addr_list(netdev);
-		if (count < 0) {
-			fctrl |= IXGBE_FCTRL_UPE;
-			vmolr |= IXGBE_VMOLR_ROPE;
-		}
+	}
+
+	/*
+	 * Write addresses to available RAR registers, if there is not
+	 * sufficient space to store all the addresses then enable
+	 * unicast promiscuous mode
+	 */
+	count = ixgbe_write_uc_addr_list(netdev);
+	if (count < 0) {
+		fctrl |= IXGBE_FCTRL_UPE;
+		vmolr |= IXGBE_VMOLR_ROPE;
 	}
 
 	if (adapter->num_vfs) {

Re: [net-next PATCH v0 5/5] ixgbe: allow RAR table to be updated in promisc mode

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Sun, 2012-03-18 at 23:52 -0700, Fastabend, John R wrote:
> This allows RAR table updates while in promiscuous. With
> SR-IOV enabled it is valuable to allow the RAR table to
> be updated even when in promisc mode to configure forwarding
> 
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> 
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   21
> +++++++++++----------
>  1 files changed, 11 insertions(+), 10 deletions(-) 

Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [net-next PATCH v0 0/5] Series short description

[David Miller]

From: John Fastabend <john.r.fastabend@intel.com>
Date: Sun, 18 Mar 2012 23:51:45 -0700

> This series is a follow up to this thread:
> 
> http://www.spinics.net/lists/netdev/msg191360.html

Can the interested parties please review this series?

I'm willing to apply this right now if it looks OK, but if
it needs more revisions we'll have to defer.

Re: [net-next PATCH v0 0/5] Series short description

[Stephen Hemminger]

On Mon, 19 Mar 2012 18:38:08 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:

> From: John Fastabend <john.r.fastabend@intel.com>
> Date: Sun, 18 Mar 2012 23:51:45 -0700
> 
> > This series is a follow up to this thread:
> > 
> > http://www.spinics.net/lists/netdev/msg191360.html
> 
> Can the interested parties please review this series?
> 
> I'm willing to apply this right now if it looks OK, but if
> it needs more revisions we'll have to defer.

Please don't rush this into this merge window. It needs more than
1 full day of review.

Re: [net-next PATCH v0 0/5] Series short description

[John Fastabend]

On 3/19/2012 3:55 PM, Stephen Hemminger wrote:
> On Mon, 19 Mar 2012 18:38:08 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
> 
>> From: John Fastabend <john.r.fastabend@intel.com>
>> Date: Sun, 18 Mar 2012 23:51:45 -0700
>>
>>> This series is a follow up to this thread:
>>>
>>> http://www.spinics.net/lists/netdev/msg191360.html
>>
>> Can the interested parties please review this series?
>>
>> I'm willing to apply this right now if it looks OK, but if
>> it needs more revisions we'll have to defer.
> 
> Please don't rush this into this merge window. It needs more than
> 1 full day of review.

Dave, its probably fine to push this to 3.5 then. I can
resubmit after you close the merge window if you want? This
has been somewhat broken for SR-IOV cards for multiple
kernel releases now anyways one more wont hurt too much.

I'll work with Roopa to get the macvlan driver plugged into
the fdb ops in the meantime and maybe get DSA as well.

Thanks,
John

Re: [net-next PATCH v0 0/5] Series short description

[David Miller]

From: John Fastabend <john.r.fastabend@intel.com>
Date: Mon, 19 Mar 2012 17:27:00 -0700

> Dave, its probably fine to push this to 3.5 then.

Fair enough.

Re: [net-next PATCH v0 0/5] Series short description

[John Fastabend]

On 3/19/2012 5:35 PM, David Miller wrote:
> From: John Fastabend <john.r.fastabend@intel.com>
> Date: Mon, 19 Mar 2012 17:27:00 -0700
> 
>> Dave, its probably fine to push this to 3.5 then.
> 
> Fair enough.

Stephen, please let me know if you see any issues though
because without these we have no way to forward packets
correctly in the embedded switch. So we can't really
use SR-IOV and virtual interfaces together correctly. And
the macvlan device in passthru mode is putting the device
in promiscuous mode which isn't great either.

.John

Re: [net-next PATCH v0 0/5] Series short description

[Stephen Hemminger]

On Mon, 19 Mar 2012 19:49:50 -0700
John Fastabend <john.r.fastabend@intel.com> wrote:

> On 3/19/2012 5:35 PM, David Miller wrote:
> > From: John Fastabend <john.r.fastabend@intel.com>
> > Date: Mon, 19 Mar 2012 17:27:00 -0700
> > 
> >> Dave, its probably fine to push this to 3.5 then.
> > 
> > Fair enough.
> 
> Stephen, please let me know if you see any issues though
> because without these we have no way to forward packets
> correctly in the embedded switch. So we can't really
> use SR-IOV and virtual interfaces together correctly. And
> the macvlan device in passthru mode is putting the device
> in promiscuous mode which isn't great either.
> 
> .John

I am more worried about evaluating ABI compatibility with older
utilities.