[RFC 0/5] bridge - introduce via_phys_dev feature

[RFC 0/5] bridge - introduce via_phys_dev feature

[Cyrill Gorcunov]

Hi,

here is RFC for new via_phys_dev bridge feature.
In short -- it allows to use some bridge port as
bridge itself with already configured routing table.

More details with example you may found in patches.

Please review. Any (including _complains_) comments are
highly appreciated!

The series is on top of current -net-next-2.6

	| commit ed9b58bc443a1210b5be1ded6421b17e015bf985
	| Author Richard Genoud <richard.genoud@gmail.com>
	| Date Sat May 9 06:59:16 2009 +0000

Cyrill

[RFC 1/5] net: bridge - use is_multicast_ether_addr helper

[Cyrill Gorcunov]

[-- Attachment #1: net-br-use-is_multicast --]
[-- Type: text/plain, Size: 707 bytes --]

Instead of handwritten constrcution it's better 
to use is_multicast_ether_addr.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
 net/bridge/br_device.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.git/net/bridge/br_device.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_device.c
+++ linux-2.6.git/net/bridge/br_device.c
@@ -32,7 +32,7 @@ int br_dev_xmit(struct sk_buff *skb, str
 	skb_reset_mac_header(skb);
 	skb_pull(skb, ETH_HLEN);
 
-	if (dest[0] & 1)
+	if (is_multicast_ether_addr(dest))
 		br_flood_deliver(br, skb);
 	else if ((dst = __br_fdb_get(br, dest)) != NULL)
 		br_deliver(dst->dst, skb);

[RFC 2/5] net: bridge - add managing of BRCTL_SET_VIA_PHYS_DEV and BRCTL_SET_MASTER_DEV

[Cyrill Gorcunov]

[-- Attachment #1: net-br-via_phys --]
[-- Type: text/plain, Size: 5210 bytes --]

Add managing via_phys_dev feature at sysctl level and ioctls as well.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---

Note: there is no changing done for __bridge_info structure and
in handling of BRCTL_GET_BRIDGE_INFO since they are part of
userspace. So returning info about master_dev could break
userpace applications. Not sure how to better handle it
and eventually decided to not touch it at all.

 include/linux/if_bridge.h |    2 ++
 net/bridge/br_if.c        |   22 ++++++++++++++++++++++
 net/bridge/br_ioctl.c     |   29 +++++++++++++++++++++++++++++
 net/bridge/br_private.h   |    2 ++
 net/bridge/br_sysfs_br.c  |   23 +++++++++++++++++++++++
 5 files changed, 78 insertions(+)

Index: linux-2.6.git/include/linux/if_bridge.h
=====================================================================
--- linux-2.6.git.orig/include/linux/if_bridge.h
+++ linux-2.6.git/include/linux/if_bridge.h
@@ -42,6 +42,8 @@
 #define BRCTL_SET_PORT_PRIORITY 16
 #define BRCTL_SET_PATH_COST 17
 #define BRCTL_GET_FDB_ENTRIES 18
+#define BRCTL_SET_VIA_PHYS_DEV 19
+#define BRCTL_SET_MASTER_DEV 20
 
 #define BR_STATE_DISABLED 0
 #define BR_STATE_LISTENING 1
Index: linux-2.6.git/net/bridge/br_if.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_if.c
+++ linux-2.6.git/net/bridge/br_if.c
@@ -158,6 +158,11 @@ static void del_br(struct net_bridge *br
 {
 	struct net_bridge_port *p, *n;
 
+	if (br->master_dev) {
+		dev_put(br->master_dev);
+		br->master_dev = NULL;
+	}
+
 	list_for_each_entry_safe(p, n, &br->port_list, list) {
 		del_nbp(p);
 	}
@@ -412,6 +417,19 @@ int br_add_if(struct net_bridge *br, str
 	if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
 	    (br->dev->flags & IFF_UP))
 		br_stp_enable_port(p);
+
+	/*
+	 * since brctl utils could not have BRCTL_SET_MASTER_DEV
+	 * yet implemented we set first port as master device
+	 * if via_phys_dev is turned on
+	 */
+	if (br->via_phys_dev) {
+		if (!br->master_dev) {
+			dev_hold(dev);
+			br->master_dev = dev;
+		}
+	}
+
 	spin_unlock_bh(&br->lock);
 
 	br_ifinfo_notify(RTM_NEWLINK, p);
@@ -446,6 +464,10 @@ int br_del_if(struct net_bridge *br, str
 	spin_lock_bh(&br->lock);
 	br_stp_recalculate_bridge_id(br);
 	br_features_recompute(br);
+	if (br->master_dev == dev) {
+		br->master_dev = NULL;
+		dev_put(dev);
+	}
 	spin_unlock_bh(&br->lock);
 
 	return 0;
Index: linux-2.6.git/net/bridge/br_ioctl.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_ioctl.c
+++ linux-2.6.git/net/bridge/br_ioctl.c
@@ -262,6 +262,35 @@ static int old_dev_ioctl(struct net_devi
 		br_stp_set_enabled(br, args[1]);
 		return 0;
 
+	case BRCTL_SET_VIA_PHYS_DEV:
+		if (!capable(CAP_NET_ADMIN))
+			return -EPERM;
+		br->via_phys_dev = args[1] ? true : false;
+		return 0;
+
+	case BRCTL_SET_MASTER_DEV:
+	{
+		struct net_device *dev;
+
+		if (!capable(CAP_NET_ADMIN))
+			return -EPERM;
+
+		if (!br->via_phys_dev) {
+			pr_debug("Bridge: turn on via_phys_dev feature first\n");
+			return -EINVAL;
+		}
+
+		dev = dev_get_by_index(dev_net(br->dev), args[1]);
+		if (dev == NULL)
+			return -EINVAL;
+
+		if (br->master_dev)
+			dev_put(br->master_dev);
+		br->master_dev = dev;
+
+		return 0;
+	}
+
 	case BRCTL_SET_BRIDGE_PRIORITY:
 		if (!capable(CAP_NET_ADMIN))
 			return -EPERM;
Index: linux-2.6.git/net/bridge/br_private.h
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_private.h
+++ linux-2.6.git/net/bridge/br_private.h
@@ -89,6 +89,8 @@ struct net_bridge
 	spinlock_t			lock;
 	struct list_head		port_list;
 	struct net_device		*dev;
+	struct net_device		*master_dev;
+	bool				via_phys_dev;
 	spinlock_t			hash_lock;
 	struct hlist_head		hash[BR_HASH_SIZE];
 	struct list_head		age_list;
Index: linux-2.6.git/net/bridge/br_sysfs_br.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_sysfs_br.c
+++ linux-2.6.git/net/bridge/br_sysfs_br.c
@@ -181,6 +181,28 @@ static ssize_t store_stp_state(struct de
 static DEVICE_ATTR(stp_state, S_IRUGO | S_IWUSR, show_stp_state,
 		   store_stp_state);
 
+static ssize_t show_via_phys_dev_state(struct device *cd,
+				struct device_attribute *attr, char *buf)
+{
+	struct net_bridge *br = to_bridge(cd);
+	return sprintf(buf, "%d\n", br->via_phys_dev);
+}
+
+static int set_via_phys_dev_state(struct net_bridge *br, unsigned long val)
+{
+	br->via_phys_dev = val ? true : false;
+	return 0;
+}
+
+static ssize_t store_via_phys_dev_state(struct device *cd,
+		struct device_attribute *attr, const char *buf, size_t len)
+{
+	return store_bridge_parm(cd, buf, len, set_via_phys_dev_state);
+}
+
+static DEVICE_ATTR(via_phys_dev, S_IRUGO | S_IWUSR, show_via_phys_dev_state,
+		store_via_phys_dev_state);
+
 static ssize_t show_priority(struct device *d, struct device_attribute *attr,
 			     char *buf)
 {
@@ -350,6 +372,7 @@ static struct attribute *bridge_attrs[] 
 	&dev_attr_max_age.attr,
 	&dev_attr_ageing_time.attr,
 	&dev_attr_stp_state.attr,
+	&dev_attr_via_phys_dev.attr,
 	&dev_attr_priority.attr,
 	&dev_attr_bridge_id.attr,
 	&dev_attr_root_id.attr,

[RFC 3/5] net: sk_buff - introduce br_seen field to mark skb issued by a bridge

[Cyrill Gorcunov]

[-- Attachment #1: net-br-introduce-skb-brmark --]
[-- Type: text/plain, Size: 1167 bytes --]

To distinguish skb's that was issued by a bridge (to not
loop forever) special skb mark is needed - br_seen.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
 include/linux/skbuff.h |    3 +++
 net/core/skbuff.c      |    3 +++
 2 files changed, 6 insertions(+)

Index: linux-2.6.git/include/linux/skbuff.h
=====================================================================
--- linux-2.6.git.orig/include/linux/skbuff.h
+++ linux-2.6.git/include/linux/skbuff.h
@@ -382,6 +382,9 @@ struct sk_buff {
 	__u8			do_not_encrypt:1;
 	__u8			requeue:1;
 #endif
+#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
+	__u8			br_seen:1;
+#endif
 	/* 0/13/14 bit hole */
 
 #ifdef CONFIG_NET_DMA
Index: linux-2.6.git/net/core/skbuff.c
=====================================================================
--- linux-2.6.git.orig/net/core/skbuff.c
+++ linux-2.6.git/net/core/skbuff.c
@@ -549,6 +549,9 @@ static void __copy_skb_header(struct sk_
 	new->tc_verd		= old->tc_verd;
 #endif
 #endif
+#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
+	new->br_seen		= old->br_seen;
+#endif
 	new->vlan_tci		= old->vlan_tci;
 
 	skb_copy_secmark(new, old);

[RFC 4/5] net: dev.c - introduce br_hard_xmit_hook

[Cyrill Gorcunov]

[-- Attachment #1: net-br-hard-xmit-hook --]
[-- Type: text/plain, Size: 2422 bytes --]

In a sake of ability to handle outgoing skb by
a bridge the br_hard_xmit_hook is added.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
 include/linux/if_bridge.h |    1 +
 net/core/dev.c            |   24 ++++++++++++++++++++++++
 2 files changed, 25 insertions(+)

Index: linux-2.6.git/include/linux/if_bridge.h
=====================================================================
--- linux-2.6.git.orig/include/linux/if_bridge.h
+++ linux-2.6.git/include/linux/if_bridge.h
@@ -109,6 +109,7 @@ struct __fdb_entry
 extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void __user *));
 extern struct sk_buff *(*br_handle_frame_hook)(struct net_bridge_port *p,
 					       struct sk_buff *skb);
+extern int (*br_hard_xmit_hook)(struct sk_buff *skb, struct net_bridge_port *port);
 extern int (*br_should_route_hook)(struct sk_buff *skb);
 
 #endif
Index: linux-2.6.git/net/core/dev.c
=====================================================================
--- linux-2.6.git.orig/net/core/dev.c
+++ linux-2.6.git/net/core/dev.c
@@ -1671,6 +1671,24 @@ static int dev_gso_segment(struct sk_buf
 	return 0;
 }
 
+#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
+int (*br_hard_xmit_hook)(struct sk_buff *skb, struct net_bridge_port *port);
+static inline int bridge_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_bridge_port *port;
+
+	port = rcu_dereference(dev->br_port);
+	if (!port || skb->br_seen)
+		return 0;
+
+	return br_hard_xmit_hook(skb, port);
+}
+#else
+static inline int bridge_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{ }
+#endif
+
+
 int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
 			struct netdev_queue *txq)
 {
@@ -1688,6 +1706,8 @@ int dev_hard_start_xmit(struct sk_buff *
 				goto gso;
 		}
 
+		bridge_hard_start_xmit(skb, dev);
+
 		rc = ops->ndo_start_xmit(skb, dev);
 		/*
 		 * TODO: if skb_orphan() was called by
@@ -1712,6 +1732,9 @@ gso:
 
 		skb->next = nskb->next;
 		nskb->next = NULL;
+
+		bridge_hard_start_xmit(skb, dev);
+
 		rc = ops->ndo_start_xmit(nskb, dev);
 		if (unlikely(rc)) {
 			nskb->next = skb->next;
@@ -5576,6 +5599,7 @@ EXPORT_SYMBOL(dev_get_flags);
 
 #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
 EXPORT_SYMBOL(br_handle_frame_hook);
+EXPORT_SYMBOL(br_hard_xmit_hook);
 EXPORT_SYMBOL(br_fdb_get_hook);
 EXPORT_SYMBOL(br_fdb_put_hook);
 #endif

[RFC 5/5] net: bridge - handle via_phys_dev feature on a bridge level

[Cyrill Gorcunov]

[-- Attachment #1: net-br-via-func --]
[-- Type: text/plain, Size: 5216 bytes --]

The idea is to use existing routing table instead of
generating new one if the bridge is to be created.

This allow to login on remote machine then create bridge
there and continue working on this machine without
session interrupted (though delay while bridge is learning
still present).

To achive this we introduce via_phys_dev feature which
force to work some real NIC as bridge.

How to use it:
 - Create a new bridge set via_phys_dev in sysfs entry for the bridge
 - Add a bridge port. This port will behave like it's a bridge
   itself, i.e. a packet recieved from network will be handled the same
   way if it was received by bridge device. Any write on this
   device from OS behaves like it is being written to bridge device
   itself too.

Typical session looks like

| ssh@10.10.0.160$ brctl addbr br0
| ssh@10.10.0.160$ ifconfig br0 up
| ssh@10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
| ssh@10.10.0.160$ brctl addif br0 eth0
| (...waiting a bit...)
| ssh@10.10.0.160$

Which implies that eth0 is already up and running.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
 net/bridge/br.c         |    2 ++
 net/bridge/br_device.c  |   37 +++++++++++++++++++++++++++++++++++++
 net/bridge/br_forward.c |    1 +
 net/bridge/br_input.c   |   14 +++++++++++++-
 net/bridge/br_private.h |    1 +
 5 files changed, 54 insertions(+), 1 deletion(-)

Index: linux-2.6.git/net/bridge/br.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br.c
+++ linux-2.6.git/net/bridge/br.c
@@ -64,6 +64,7 @@ static int __init br_init(void)
 
 	brioctl_set(br_ioctl_deviceless_stub);
 	br_handle_frame_hook = br_handle_frame;
+	br_hard_xmit_hook = br_hard_xmit;
 
 	br_fdb_get_hook = br_fdb_get;
 	br_fdb_put_hook = br_fdb_put;
@@ -99,6 +100,7 @@ static void __exit br_deinit(void)
 	br_fdb_put_hook = NULL;
 
 	br_handle_frame_hook = NULL;
+	br_hard_xmit_hook = NULL;
 	br_fdb_fini();
 }
 
Index: linux-2.6.git/net/bridge/br_device.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_device.c
+++ linux-2.6.git/net/bridge/br_device.c
@@ -32,6 +32,8 @@ int br_dev_xmit(struct sk_buff *skb, str
 	skb_reset_mac_header(skb);
 	skb_pull(skb, ETH_HLEN);
 
+	skb->br_seen = 1;
+
 	if (is_multicast_ether_addr(dest))
 		br_flood_deliver(br, skb);
 	else if ((dst = __br_fdb_get(br, dest)) != NULL)
@@ -42,6 +44,41 @@ int br_dev_xmit(struct sk_buff *skb, str
 	return 0;
 }
 
+int br_hard_xmit(struct sk_buff *skb, struct net_bridge_port *port)
+{
+	struct net_bridge *br = port->br;
+	const unsigned char *dest = skb->data;
+	struct net_bridge_fdb_entry *dst;
+	struct sk_buff *skb2;
+
+	/* forward via master device only */
+	if (!br->via_phys_dev || br->master_dev != port->dev)
+		return 0;
+
+	skb2 = skb_clone(skb, GFP_ATOMIC);
+	if (!skb2) {
+		br->dev->stats.tx_dropped++;
+		return 0;
+	}
+
+	br->dev->stats.tx_packets++;
+	br->dev->stats.tx_bytes += skb->len;
+
+	skb_reset_mac_header(skb2);
+	skb_pull(skb2, ETH_HLEN);
+
+	skb->br_seen = 1;
+
+	if (is_multicast_ether_addr(dest))
+		br_flood_deliver(br, skb2);
+	else if ((dst = __br_fdb_get(br, dest)) != NULL)
+		br_deliver(dst->dst, skb2);
+	else
+		br_flood_deliver(br, skb2);
+
+	return 0;
+}
+
 static int br_dev_open(struct net_device *dev)
 {
 	struct net_bridge *br = netdev_priv(dev);
Index: linux-2.6.git/net/bridge/br_forward.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_forward.c
+++ linux-2.6.git/net/bridge/br_forward.c
@@ -148,5 +148,6 @@ void br_flood_deliver(struct net_bridge 
 /* called under bridge lock */
 void br_flood_forward(struct net_bridge *br, struct sk_buff *skb)
 {
+	skb->br_seen = 1;
 	br_flood(br, skb, __br_forward);
 }
Index: linux-2.6.git/net/bridge/br_input.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_input.c
+++ linux-2.6.git/net/bridge/br_input.c
@@ -28,7 +28,15 @@ static void br_pass_frame_up(struct net_
 	brdev->stats.rx_bytes += skb->len;
 
 	indev = skb->dev;
-	skb->dev = brdev;
+
+	if (br->via_phys_dev) {
+		skb->br_seen = 1;
+		if (likely(br->master_dev))
+			skb->dev = br->master_dev;
+		else
+			skb->dev = brdev;
+	} else
+		skb->dev = brdev;
 
 	NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, indev, NULL,
 		netif_receive_skb);
@@ -151,6 +159,10 @@ struct sk_buff *br_handle_frame(struct n
 		}
 		/* fall through */
 	case BR_STATE_LEARNING:
+		/* if we saw this skb earlier just pass it up */
+		if (skb->br_seen)
+			return skb;
+
 		if (!compare_ether_addr(p->br->dev->dev_addr, dest))
 			skb->pkt_type = PACKET_HOST;
 
Index: linux-2.6.git/net/bridge/br_private.h
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_private.h
+++ linux-2.6.git/net/bridge/br_private.h
@@ -144,6 +144,7 @@ static inline int br_is_root_bridge(cons
 /* br_device.c */
 extern void br_dev_setup(struct net_device *dev);
 extern int br_dev_xmit(struct sk_buff *skb, struct net_device *dev);
+extern int br_hard_xmit(struct sk_buff *skb, struct net_bridge_port *port);
 
 /* br_fdb.c */
 extern int br_fdb_init(void);

Re: [RFC 5/5] net: bridge - handle via_phys_dev feature on a bridge level

[Cyrill Gorcunov]

quilt didn't get refreshed copy. here is an updated
one. sorry for inconvenience.

	-- Cyrill
---
From: Cyrill Gorcunov <gorcunov@gmail.com>
Subject: [RFC 5/5] net: bridge - handle via_phys_dev feature on a bridge level

The idea is to use existing routing table instead of
generating new one if the bridge is to be created.

This allow to login on remote machine then create bridge
there and continue working on this machine without
session interrupted (though delay while bridge is learning
still present).

To achive this we introduce via_phys_dev feature which
force to work some real NIC as bridge.

How to use it:
 - Create a new bridge set via_phys_dev in sysfs entry for the bridge
 - Add a bridge port. This port will behave like it's a bridge
   itself, i.e. a packet recieved from network will be handled the same
   way if it was received by bridge device. Any write on this
   device from OS behaves like it is being written to bridge device
   itself too.

Typical session looks like

| ssh@10.10.0.160$ brctl addbr br0
| ssh@10.10.0.160$ ifconfig br0 up
| ssh@10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
| ssh@10.10.0.160$ brctl addif br0 eth0
| (...waiting a bit...)
| ssh@10.10.0.160$

Which implies that eth0 is already up and running.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
 net/bridge/br.c         |    2 ++
 net/bridge/br_device.c  |   37 +++++++++++++++++++++++++++++++++++++
 net/bridge/br_forward.c |    1 +
 net/bridge/br_input.c   |   14 +++++++++++++-
 net/bridge/br_private.h |    1 +
 5 files changed, 54 insertions(+), 1 deletion(-)

Index: linux-2.6.git/net/bridge/br.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br.c
+++ linux-2.6.git/net/bridge/br.c
@@ -64,6 +64,7 @@ static int __init br_init(void)
 
 	brioctl_set(br_ioctl_deviceless_stub);
 	br_handle_frame_hook = br_handle_frame;
+	br_hard_xmit_hook = br_hard_xmit;
 
 	br_fdb_get_hook = br_fdb_get;
 	br_fdb_put_hook = br_fdb_put;
@@ -99,6 +100,7 @@ static void __exit br_deinit(void)
 	br_fdb_put_hook = NULL;
 
 	br_handle_frame_hook = NULL;
+	br_hard_xmit_hook = NULL;
 	br_fdb_fini();
 }
 
Index: linux-2.6.git/net/bridge/br_device.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_device.c
+++ linux-2.6.git/net/bridge/br_device.c
@@ -32,6 +32,8 @@ int br_dev_xmit(struct sk_buff *skb, str
 	skb_reset_mac_header(skb);
 	skb_pull(skb, ETH_HLEN);
 
+	skb->br_seen = 1;
+
 	if (is_multicast_ether_addr(dest))
 		br_flood_deliver(br, skb);
 	else if ((dst = __br_fdb_get(br, dest)) != NULL)
@@ -42,6 +44,41 @@ int br_dev_xmit(struct sk_buff *skb, str
 	return 0;
 }
 
+int br_hard_xmit(struct sk_buff *skb, struct net_bridge_port *port)
+{
+	struct net_bridge *br = port->br;
+	const unsigned char *dest = skb->data;
+	struct net_bridge_fdb_entry *dst;
+	struct sk_buff *skb2;
+
+	/* forward via master device only */
+	if (!br->via_phys_dev || br->master_dev != port->dev)
+		return 0;
+
+	skb2 = skb_clone(skb, GFP_ATOMIC);
+	if (!skb2) {
+		br->dev->stats.tx_dropped++;
+		return 0;
+	}
+
+	br->dev->stats.tx_packets++;
+	br->dev->stats.tx_bytes += skb2->len;
+
+	skb_reset_mac_header(skb2);
+	skb_pull(skb2, ETH_HLEN);
+
+	skb2->br_seen = 1;
+
+	if (is_multicast_ether_addr(dest))
+		br_flood_deliver(br, skb2);
+	else if ((dst = __br_fdb_get(br, dest)) != NULL)
+		br_deliver(dst->dst, skb2);
+	else
+		br_flood_deliver(br, skb2);
+
+	return 0;
+}
+
 static int br_dev_open(struct net_device *dev)
 {
 	struct net_bridge *br = netdev_priv(dev);
Index: linux-2.6.git/net/bridge/br_forward.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_forward.c
+++ linux-2.6.git/net/bridge/br_forward.c
@@ -148,5 +148,6 @@ void br_flood_deliver(struct net_bridge 
 /* called under bridge lock */
 void br_flood_forward(struct net_bridge *br, struct sk_buff *skb)
 {
+	skb->br_seen = 1;
 	br_flood(br, skb, __br_forward);
 }
Index: linux-2.6.git/net/bridge/br_input.c
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_input.c
+++ linux-2.6.git/net/bridge/br_input.c
@@ -28,7 +28,15 @@ static void br_pass_frame_up(struct net_
 	brdev->stats.rx_bytes += skb->len;
 
 	indev = skb->dev;
-	skb->dev = brdev;
+
+	if (br->via_phys_dev) {
+		skb->br_seen = 1;
+		if (likely(br->master_dev))
+			skb->dev = br->master_dev;
+		else
+			skb->dev = brdev;
+	} else
+		skb->dev = brdev;
 
 	NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, indev, NULL,
 		netif_receive_skb);
@@ -151,6 +159,10 @@ struct sk_buff *br_handle_frame(struct n
 		}
 		/* fall through */
 	case BR_STATE_LEARNING:
+		/* if we saw this skb earlier just pass it up */
+		if (skb->br_seen)
+			return skb;
+
 		if (!compare_ether_addr(p->br->dev->dev_addr, dest))
 			skb->pkt_type = PACKET_HOST;
 
Index: linux-2.6.git/net/bridge/br_private.h
=====================================================================
--- linux-2.6.git.orig/net/bridge/br_private.h
+++ linux-2.6.git/net/bridge/br_private.h
@@ -144,6 +144,7 @@ static inline int br_is_root_bridge(cons
 /* br_device.c */
 extern void br_dev_setup(struct net_device *dev);
 extern int br_dev_xmit(struct sk_buff *skb, struct net_device *dev);
+extern int br_hard_xmit(struct sk_buff *skb, struct net_bridge_port *port);
 
 /* br_fdb.c */
 extern int br_fdb_init(void);

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Daniel Robbins]

Note: I am not a bridge guru but I'm interested in understanding this
new functionality better. What is the larger benefit of this feature?
Does this make it possible to configure a bridge setup on a remote
system without losing connectivity? I can't do many kinds of network
changes remotely without risking losing connectivity (ie. changing IP
address, messing with routing, etc. -- it would be likely that you'd
lose network connectivity :) ) Therefore, I don't know if this is a
benefit unless it is needed for a particular application. Is this
useful for OpenVZ in some way?

Regards,

Daniel

On Mon, May 11, 2009 at 5:46 AM, Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> Hi,
>
> here is RFC for new via_phys_dev bridge feature.
> In short -- it allows to use some bridge port as
> bridge itself with already configured routing table.
>
> More details with example you may found in patches.
>
> Please review. Any (including _complains_) comments are
> highly appreciated!
>
> The series is on top of current -net-next-2.6
>
>        | commit ed9b58bc443a1210b5be1ded6421b17e015bf985
>        | Author Richard Genoud <richard.genoud@gmail.com>
>        | Date Sat May 9 06:59:16 2009 +0000
>
> Cyrill
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Cyrill Gorcunov]

On 5/12/09, Daniel Robbins <drobbins@funtoo.org> wrote:
> Note: I am not a bridge guru but I'm interested in understanding this
> new functionality better. What is the larger benefit of this feature?
> Does this make it possible to configure a bridge setup on a remote
> system without losing connectivity? I can't do many kinds of network
> changes remotely without risking losing connectivity (ie. changing IP
> address, messing with routing, etc. -- it would be likely that you'd
> lose network connectivity :) ) Therefore, I don't know if this is a
> benefit unless it is needed for a particular application. Is this
> useful for OpenVZ in some way?
>
> Regards,
>
> Daniel
>
Hi Daniel,

The idea was exactly you described, ie have an ability to configure
remote system as bridge. There was an example how to use it in the
pach (last patch in series). Say we have remote system with eth0 set
up and running. So we may sign in into this system remotely. If we
have to confugure bridge on such a system (that even eth0 has to be
the bridge port) we connect to this system via eth0 then add bridge
br0 and run it via ifconfig br0 up, turn on via_phys_dev feature and
evetually add eth0 as a bridge port. We will have small delay in
session until port get forwarding state but after we could continue
work remotely on the system without reconfiguring routing table. Even
ssh session being used during configuration will continue operate. So
except a delay no session interrupt. I hope, need a good testing ;)

> On Mon, May 11, 2009 at 5:46 AM, Cyrill Gorcunov <gorcunov@openvz.org>
> wrote:
>> Hi,
>>
>> here is RFC for new via_phys_dev bridge feature.
>> In short -- it allows to use some bridge port as
>> bridge itself with already configured routing table.
>>
>> More details with example you may found in patches.
>>
>> Please review. Any (including _complains_) comments are
>> highly appreciated!
>>
>> The series is on top of current -net-next-2.6
>>
>>        | commit ed9b58bc443a1210b5be1ded6421b17e015bf985
>>        | Author Richard Genoud <richard.genoud@gmail.com>
>>        | Date Sat May 9 06:59:16 2009 +0000
>>
>> Cyrill
>> _______________________________________________
>> Bridge mailing list
>> Bridge@lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/bridge
>>
>

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Daniel Robbins]

Is this functionality useful for OpenVZ? Do people need the ability to
do this? Why/when is it necessary for me to be able to add eth0 to a
bridge remotely?

I don't quite (yet) understand the usefulness of this feature. You
would still be very limited in what you can change with the network if
you are remote, right? That's why I don't quite understand the benefit
of this feature. How are you planning to use it? When I set up my
OpenVZ systems, I like to get the overall network/bridge configuration
perfect so that I don't need to make major changes when I am remote.

Again, I am not an expert so I am asking purely for my own curiosity.
I support the idea of making networking more flexible, but I do not
see this particular step addressed by the patch as a common need. That
may be due to my own lack of understanding.

I am a big fan of OpenVZ though, so if it helps OpenVZ in some way,
I'd like to know about it :)

-Daniel

On Tue, May 12, 2009 at 12:19 AM, Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> On 5/12/09, Daniel Robbins <drobbins@funtoo.org> wrote:
>> Note: I am not a bridge guru but I'm interested in understanding this
>> new functionality better. What is the larger benefit of this feature?
>> Does this make it possible to configure a bridge setup on a remote
>> system without losing connectivity? I can't do many kinds of network
>> changes remotely without risking losing connectivity (ie. changing IP
>> address, messing with routing, etc. -- it would be likely that you'd
>> lose network connectivity :) ) Therefore, I don't know if this is a
>> benefit unless it is needed for a particular application. Is this
>> useful for OpenVZ in some way?
>>
>> Regards,
>>
>> Daniel
>>
> Hi Daniel,
>
> The idea was exactly you described, ie have an ability to configure
> remote system as bridge. There was an example how to use it in the
> pach (last patch in series). Say we have remote system with eth0 set
> up and running. So we may sign in into this system remotely. If we
> have to confugure bridge on such a system (that even eth0 has to be
> the bridge port) we connect to this system via eth0 then add bridge
> br0 and run it via ifconfig br0 up, turn on via_phys_dev feature and
> evetually add eth0 as a bridge port. We will have small delay in
> session until port get forwarding state but after we could continue
> work remotely on the system without reconfiguring routing table. Even
> ssh session being used during configuration will continue operate. So
> except a delay no session interrupt. I hope, need a good testing ;)
>
>> On Mon, May 11, 2009 at 5:46 AM, Cyrill Gorcunov <gorcunov@openvz.org>
>> wrote:
>>> Hi,
>>>
>>> here is RFC for new via_phys_dev bridge feature.
>>> In short -- it allows to use some bridge port as
>>> bridge itself with already configured routing table.
>>>
>>> More details with example you may found in patches.
>>>
>>> Please review. Any (including _complains_) comments are
>>> highly appreciated!
>>>
>>> The series is on top of current -net-next-2.6
>>>
>>>        | commit ed9b58bc443a1210b5be1ded6421b17e015bf985
>>>        | Author Richard Genoud <richard.genoud@gmail.com>
>>>        | Date Sat May 9 06:59:16 2009 +0000
>>>
>>> Cyrill
>>> _______________________________________________
>>> Bridge mailing list
>>> Bridge@lists.linux-foundation.org
>>> https://lists.linux-foundation.org/mailman/listinfo/bridge
>>>
>>
>

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Cyrill Gorcunov]

[Daniel Robbins - Tue, May 12, 2009 at 01:02:01AM -0600]
|
| Is this functionality useful for OpenVZ? Do people need the ability to
| do this? Why/when is it necessary for me to be able to add eth0 to a
| bridge remotely?
| 

As far as I know (fix me if I'm wrong) you're not able to configure
bridge remotely from the scratch via active port (say eth0) without
interrupting the session and recreating routing table. Of course you
could have a script which will do all work for you. (or you could
be having a machine with 3/4/5/10 NIC's and one of them could be
just reserved to be used remote access only with proper routing
table, etc...). But in case if all nics are to be used as bridge
ports and you still need to access such a machine remotely i believe
via_phys_dev could be our friend :)

So, Daniel, i think the right question is -- do I ever need to
configure/setup bridge remotely? I suppose yes, it happens.
(at least I had a machine with lack of input device except a few
 NICs :-)

|
| I don't quite (yet) understand the usefulness of this feature. You
| would still be very limited in what you can change with the network if
| you are remote, right? That's why I don't quite understand the benefit
| of this feature. How are you planning to use it? When I set up my
| OpenVZ systems, I like to get the overall network/bridge configuration
| perfect so that I don't need to make major changes when I am remote.
|

This feature already was in OpenVZ 2.6.24 kernel. I'm more intiresting in
usefulness of this feature for the mainline. (in short -- we use it for bridging
VEs with eth0 as a master device so all works without needing to
reconfigure routing table). Moreover, since bridge already support
namespacing the feature could be usefull for lxc as well (though
didn't check to be fair).

| 
| Again, I am not an expert so I am asking purely for my own curiosity.
| I support the idea of making networking more flexible, but I do not
| see this particular step addressed by the patch as a common need. That
| may be due to my own lack of understanding.
| 

That is why it's RFC so people could decide should it be included
into mainline or not. Worth it so or not.

|
| I am a big fan of OpenVZ though, so if it helps OpenVZ in some way,
| I'd like to know about it :)
|

Yes it helps to bridge VE's without reconstructing routing table
on HW node.

| 
| -Daniel
| 
 
	-- Cyrill

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Daniel Robbins]

On Tue, May 12, 2009 at 10:24 AM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> So, Daniel, i think the right question is -- do I ever need to
> configure/setup bridge remotely? I suppose yes, it happens.
> (at least I had a machine with lack of input device except a few
>  NICs :-)

Aha, yes it would be useful in that case :)

So is the idea that you use via_phys_dev *temporarily* when
configuring the bridge, then you get it set up the way you want, and
then maybe you reboot the machine, and this time leave via_phys_dev
off? Or are there certain cases you can envision where you might want
this enabled permanently?

> This feature already was in OpenVZ 2.6.24 kernel. I'm more intiresting in
> usefulness of this feature for the mainline. (in short -- we use it for bridging
> VEs with eth0 as a master device so all works without needing to
> reconfigure routing table). Moreover, since bridge already support
> namespacing the feature could be usefull for lxc as well (though
> didn't check to be fair).

But not in the OpenVZ 2.6.27-briullov kernel yet, at least the one I'm
running :)

> That is why it's RFC so people could decide should it be included
> into mainline or not. Worth it so or not.

If it is accepted into mainline, be sure to send Stephen some
documentation on this feature so he can add it to the net:bridge docs.
When features like this aren't documented, no one knows how to use
them. I just ran into this issue with the 2.6.27+ "sticky" bridge MAC
feature. I'd also be willing to help keeping the bridge docs
up-to-date. Please let me know if you or Stephen want me to do this.
Bridging is really important for OpenVZ and other
container/paravirtualization technologies so keeping docs up-to-date
is becoming more important. It can be useful to have a
non-kernel-developer like me document the functionality.

Best Regards,

Daniel

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Cyrill Gorcunov]

[Daniel Robbins - Tue, May 12, 2009 at 11:07:14AM -0600]
| On Tue, May 12, 2009 at 10:24 AM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
| > So, Daniel, i think the right question is -- do I ever need to
| > configure/setup bridge remotely? I suppose yes, it happens.
| > (at least I had a machine with lack of input device except a few
| >  NICs :-)
| 
| Aha, yes it would be useful in that case :)
| 
| So is the idea that you use via_phys_dev *temporarily* when
| configuring the bridge, then you get it set up the way you want, and
| then maybe you reboot the machine, and this time leave via_phys_dev
| off? Or are there certain cases you can envision where you might want
| this enabled permanently?

You could turn this feature on while configuring bridge, then as only
you have done all you need you just turn it off and bridge back to its
regular behaviour (and remote connection lost of course). So no need
for reboot. At moment sysfs entry is added and ioctls as well (though
bridge utils need some change to support new ioctls).

Permanently... it could be usefull if you initially planned to have remote
access to bridge-master machine. Ie instead to set up IP for bridge
device you remain with master device IP (say eth0).

| 
| > This feature already was in OpenVZ 2.6.24 kernel. I'm more intiresting in
| > usefulness of this feature for the mainline. (in short -- we use it for bridging
| > VEs with eth0 as a master device so all works without needing to
| > reconfigure routing table). Moreover, since bridge already support
| > namespacing the feature could be usefull for lxc as well (though
| > didn't check to be fair).
| 
| But not in the OpenVZ 2.6.27-briullov kernel yet, at least the one I'm
| running :)

it's just a quiestion of time :)

| 
| > That is why it's RFC so people could decide should it be included
| > into mainline or not. Worth it so or not.
| 
| If it is accepted into mainline, be sure to send Stephen some
| documentation on this feature so he can add it to the net:bridge docs.
| When features like this aren't documented, no one knows how to use
| them. I just ran into this issue with the 2.6.27+ "sticky" bridge MAC
| feature. I'd also be willing to help keeping the bridge docs
| up-to-date. Please let me know if you or Stephen want me to do this.
| Bridging is really important for OpenVZ and other
| container/paravirtualization technologies so keeping docs up-to-date
| is becoming more important. It can be useful to have a
| non-kernel-developer like me document the functionality.

Of course, though with my english better to not touch docs :)

But again -- this series requires _strong_ review and testing
(since I'm not a netdevel expert)

| 
| Best Regards,
| 
| Daniel
| 
	-- Cyrill

Re: [RFC 1/5] net: bridge - use is_multicast_ether_addr helper

[Stephen Hemminger]

On Mon, 11 May 2009 15:46:40 +0400
Cyrill Gorcunov <gorcunov@openvz.org> wrote:

> Instead of handwritten constrcution it's better 
> to use is_multicast_ether_addr.
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> ---
>  net/bridge/br_device.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.git/net/bridge/br_device.c
> =====================================================================
> --- linux-2.6.git.orig/net/bridge/br_device.c
> +++ linux-2.6.git/net/bridge/br_device.c
> @@ -32,7 +32,7 @@ int br_dev_xmit(struct sk_buff *skb, str
>  	skb_reset_mac_header(skb);
>  	skb_pull(skb, ETH_HLEN);
>  
> -	if (dest[0] & 1)
> +	if (is_multicast_ether_addr(dest))
>  		br_flood_deliver(br, skb);
>  	else if ((dst = __br_fdb_get(br, dest)) != NULL)
>  		br_deliver(dst->dst, skb);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


This is trivial and fine.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Stephen Hemminger]

On Mon, 11 May 2009 15:46:39 +0400
Cyrill Gorcunov <gorcunov@openvz.org> wrote:

> Hi,
> 
> here is RFC for new via_phys_dev bridge feature.
> In short -- it allows to use some bridge port as
> bridge itself with already configured routing table.
> 
> More details with example you may found in patches.
> 
> Please review. Any (including _complains_) comments are
> highly appreciated!
> 
> The series is on top of current -net-next-2.6
> 
> 	| commit ed9b58bc443a1210b5be1ded6421b17e015bf985
> 	| Author Richard Genoud <richard.genoud@gmail.com>
> 	| Date Sat May 9 06:59:16 2009 +0000
> 
> Cyrill
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Do not really like this patch set. It adds more complexity to solve a problem
that looks like it can be solved by other means.

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Stephen Hemminger]

Looking back at this. What if the API was simpler:

Instead of:
> Typical session looks like
> 
> | s...@10.10.0.160$ brctl addbr br0
> | s...@10.10.0.160$ ifconfig br0 up
> | s...@10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
> | s...@10.10.0.160$ brctl addif br0 eth0
> | (...waiting a bit...)
> | s...@10.10.0.160$

Why not:
  1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
  2. Add eth0 to bridge with new flag to inherit
       a. brctl addif br0 eth0 inherit

Inherit functionality would need to move address (Ether, IP, IPv6)
and routes from eth0 to br0.
I will see about doing it as much as possible in userspace.

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Cyrill Gorcunov]

On Fri, Feb 26, 2010 at 08:18:43AM -0800, Stephen Hemminger wrote:
> Looking back at this. What if the API was simpler:
> 
> Instead of:
> > Typical session looks like
> > 
> > | s...@10.10.0.160$ brctl addbr br0
> > | s...@10.10.0.160$ ifconfig br0 up
> > | s...@10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
> > | s...@10.10.0.160$ brctl addif br0 eth0
> > | (...waiting a bit...)
> > | s...@10.10.0.160$
> 
> Why not:
>   1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
>   2. Add eth0 to bridge with new flag to inherit
>        a. brctl addif br0 eth0 inherit
> 
> Inherit functionality would need to move address (Ether, IP, IPv6)
> and routes from eth0 to br0.
> I will see about doing it as much as possible in userspace.
> 

Looks promising for me (CC'ed a few people just to be sure I'm not
missing anything).

	-- Cyrill

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[richardvoigt]

On Fri, Feb 26, 2010 at 10:18 AM, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> Looking back at this. What if the API was simpler:
>
> Instead of:
>> Typical session looks like
>>
>> | s...@10.10.0.160$ brctl addbr br0
>> | s...@10.10.0.160$ ifconfig br0 up
>> | s...@10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
>> | s...@10.10.0.160$ brctl addif br0 eth0
>> | (...waiting a bit...)
>> | s...@10.10.0.160$
>
> Why not:
>  1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
>  2. Add eth0 to bridge with new flag to inherit
>       a. brctl addif br0 eth0 inherit
>
> Inherit functionality would need to move address (Ether, IP, IPv6)
> and routes from eth0 to br0.
> I will see about doing it as much as possible in userspace.

How about inheriting the up/down status as well, this way the bridge
can be left down until the settings are inherited, and will come up
with the inherited MAC address, IP address, and routing table instead
of changing while live?

> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

Re: [Bridge] [RFC 0/5] bridge - introduce via_phys_dev feature

[Stephen Hemminger]

On Fri, 26 Feb 2010 10:52:52 -0600
"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote:

> On Fri, Feb 26, 2010 at 10:18 AM, Stephen Hemminger
> <shemminger@linux-foundation.org> wrote:
> > Looking back at this. What if the API was simpler:
> >
> > Instead of:
> >> Typical session looks like
> >>
> >> | s...@10.10.0.160$ brctl addbr br0
> >> | s...@10.10.0.160$ ifconfig br0 up
> >> | s...@10.10.0.160$ echo 1 > /sys/class/net/bridge/br0/via_phys_dev
> >> | s...@10.10.0.160$ brctl addif br0 eth0
> >> | (...waiting a bit...)
> >> | s...@10.10.0.160$
> >
> > Why not:
> >  1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
> >  2. Add eth0 to bridge with new flag to inherit
> >       a. brctl addif br0 eth0 inherit
> >
> > Inherit functionality would need to move address (Ether, IP, IPv6)
> > and routes from eth0 to br0.
> > I will see about doing it as much as possible in userspace.
> 
> How about inheriting the up/down status as well, this way the bridge
> can be left down until the settings are inherited, and will come up
> with the inherited MAC address, IP address, and routing table instead
> of changing while live?

Ok.

-- 

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Pavel Emelyanov]

Cyrill Gorcunov wrote:
> On Fri, Feb 26, 2010 at 08:18:43AM -0800, Stephen Hemminger wrote:
>> Looking back at this. What if the API was simpler:

Thanks for the reply, Stephen!

>> Why not:
>>   1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
>>   2. Add eth0 to bridge with new flag to inherit
>>        a. brctl addif br0 eth0 inherit
>>
>> Inherit functionality would need to move address (Ether, IP, IPv6)
>> and routes from eth0 to br0.
>> I will see about doing it as much as possible in userspace.
>>

Solution is good, but we'll have to reconfigure netfilter matches
that check for device name/ifindex and restore all this back when
deleting eth0 from br0.

Maybe it's better to implement it on the kernel side by sending a 
netdev notification and letting the subsystem reconfigure themselves?

And what can we do with existing TCP connections bound to a device?

> 	-- Cyrill

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Stephen Hemminger]

On Fri, 26 Feb 2010 20:39:59 +0300
Pavel Emelyanov <xemul@openvz.org> wrote:

> Cyrill Gorcunov wrote:
> > On Fri, Feb 26, 2010 at 08:18:43AM -0800, Stephen Hemminger wrote:
> >> Looking back at this. What if the API was simpler:
> 
> Thanks for the reply, Stephen!
> 
> >> Why not:
> >>   1. Setup bridge (and any other interfaces except eth0); includes bringing br0 up
> >>   2. Add eth0 to bridge with new flag to inherit
> >>        a. brctl addif br0 eth0 inherit
> >>
> >> Inherit functionality would need to move address (Ether, IP, IPv6)
> >> and routes from eth0 to br0.
> >> I will see about doing it as much as possible in userspace.
> >>
> 
> Solution is good, but we'll have to reconfigure netfilter matches
> that check for device name/ifindex and restore all this back when
> deleting eth0 from br0.

Netfilter is outside of this, and can't really migrate easily.

> Maybe it's better to implement it on the kernel side by sending a 
> netdev notification and letting the subsystem reconfigure themselves?
> 
> And what can we do with existing TCP connections bound to a device?
> 

TCP connections are never really bound to device. TCP routing is
flexible; if packets can get through, it doesn't care.

-- 

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 26 Feb 2010 10:01:02 -0800

> TCP connections are never really bound to device. TCP routing is
> flexible; if packets can get through, it doesn't care.

I think he might be talking about SO_BINDTODEVICE

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Stephen Hemminger]

On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Fri, 26 Feb 2010 10:01:02 -0800
> 
> > TCP connections are never really bound to device. TCP routing is
> > flexible; if packets can get through, it doesn't care.
> 
> I think he might be talking about SO_BINDTODEVICE

What application does that with TCP?

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Ben Greear]

On 02/26/2010 10:30 AM, Stephen Hemminger wrote:
> On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
> David Miller<davem@davemloft.net>  wrote:
>
>> From: Stephen Hemminger<shemminger@linux-foundation.org>
>> Date: Fri, 26 Feb 2010 10:01:02 -0800
>>
>>> TCP connections are never really bound to device. TCP routing is
>>> flexible; if packets can get through, it doesn't care.
>>
>> I think he might be talking about SO_BINDTODEVICE
>
> What application does that with TCP?

I use it..helps with using multiple interfaces on the same system,
especially when sending-to-self.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Stephen Hemminger]

On Fri, 26 Feb 2010 10:40:46 -0800
Ben Greear <greearb@candelatech.com> wrote:

> On 02/26/2010 10:30 AM, Stephen Hemminger wrote:
> > On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
> > David Miller<davem@davemloft.net>  wrote:
> >
> >> From: Stephen Hemminger<shemminger@linux-foundation.org>
> >> Date: Fri, 26 Feb 2010 10:01:02 -0800
> >>
> >>> TCP connections are never really bound to device. TCP routing is
> >>> flexible; if packets can get through, it doesn't care.
> >>
> >> I think he might be talking about SO_BINDTODEVICE
> >
> > What application does that with TCP?
> 
> I use it..helps with using multiple interfaces on the same system,
> especially when sending-to-self.
> 

That is a special case which is not related to the discussion.
We are talking about being able to setup a bridge and migrate the
associated state from the ethernet device to the bridge.

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Cyrill Gorcunov]

On Fri, Feb 26, 2010 at 10:30:03AM -0800, Stephen Hemminger wrote:
> On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Stephen Hemminger <shemminger@linux-foundation.org>
> > Date: Fri, 26 Feb 2010 10:01:02 -0800
> > 
> > > TCP connections are never really bound to device. TCP routing is
> > > flexible; if packets can get through, it doesn't care.
> > 
> > I think he might be talking about SO_BINDTODEVICE
> 
> What application does that with TCP?
> 

Seems g500i uses it http://goo.gl/5lIi (function open_tcp_socket),
which is either router firmware or kind of modile device.
But frankly -- this seems to be unrelated to a bridge.

	-- Cyrill

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 26 Feb 2010 10:30:03 -0800

> On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
> 
>> From: Stephen Hemminger <shemminger@linux-foundation.org>
>> Date: Fri, 26 Feb 2010 10:01:02 -0800
>> 
>> > TCP connections are never really bound to device. TCP routing is
>> > flexible; if packets can get through, it doesn't care.
>> 
>> I think he might be talking about SO_BINDTODEVICE
> 
> What application does that with TCP?

Any application that would like to, it's been supported from day one.

In fact I bet there are more TCP applications that support
SO_BINDTODEVICE than UDP ones.

Re: [RFC 0/5] bridge - introduce via_phys_dev feature

[Pavel Emelyanov]

Stephen Hemminger wrote:
> On Fri, 26 Feb 2010 10:40:46 -0800
> Ben Greear <greearb@candelatech.com> wrote:
> 
>> On 02/26/2010 10:30 AM, Stephen Hemminger wrote:
>>> On Fri, 26 Feb 2010 10:08:00 -0800 (PST)
>>> David Miller<davem@davemloft.net>  wrote:
>>>
>>>> From: Stephen Hemminger<shemminger@linux-foundation.org>
>>>> Date: Fri, 26 Feb 2010 10:01:02 -0800
>>>>
>>>>> TCP connections are never really bound to device. TCP routing is
>>>>> flexible; if packets can get through, it doesn't care.
>>>> I think he might be talking about SO_BINDTODEVICE
>>> What application does that with TCP?
>> I use it..helps with using multiple interfaces on the same system,
>> especially when sending-to-self.
>>
> 
> That is a special case which is not related to the discussion.
> We are talking about being able to setup a bridge and migrate the
> associated state from the ethernet device to the bridge.

Well, actually the intention was to discuss all the related issues.
I do agree with the proposal of the "inherit" made in userspace, but
I'd also like to know your opinion about the netfilter question I 
asked in another e-mail and this issue.

Thanks,
Pavel