[PATCH 0/3] bridge: Some nice new things for vlan filtering

[PATCH 0/3] bridge: Some nice new things for vlan filtering

[Vladislav Yasevich]

While working with vlan filtering and non-promisc mode, I've found
myself wanting untagged traffic to automatically pass through the
bridge.  So I decided to introduce the concept of a per bridge default
pvid.  VLAN 1 is used as default pvid by default and can be changed
by user through sysfs while vlan filtering is off. (I'll be adding netlink
support now that Jiri Pirko kindly added the ifrastructure).  Default
pvid is assigned to all ports that do not assign their own pvid or
already have a given vlan configured.  This makes it very simple
to enable vlan filtering on the bridge, not have to configure a thing,
and still pass untagged traffic.

The other small thing this series adds is automatic update of the
vlan filter when vlan is configured on top of the bridge.  In this
case we automatically add the given vlan to the bridge filter list.
The ports may still need to be updated as we don't know which ports
are allowed to receive a given vlan.

Thanks
-vlad

Vladislav Yasevich (3):
  bridge: Add a default_pvid sysfs attribute
  bridge: Add filtering support for default_pvid
  bridge; Automatically filter vlans configured on top of bridge

 net/bridge/br_device.c   |  54 +++++++++++++++++++---
 net/bridge/br_if.c       |   2 +
 net/bridge/br_private.h  |  35 ++++++++++++++-
 net/bridge/br_sysfs_br.c |  17 +++++++
 net/bridge/br_vlan.c     | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
 5 files changed, 213 insertions(+), 8 deletions(-)

-- 
1.9.3

[Bridge] [PATCH 0/3] bridge: Some nice new things for vlan filtering

[Vladislav Yasevich]

While working with vlan filtering and non-promisc mode, I've found
myself wanting untagged traffic to automatically pass through the
bridge.  So I decided to introduce the concept of a per bridge default
pvid.  VLAN 1 is used as default pvid by default and can be changed
by user through sysfs while vlan filtering is off. (I'll be adding netlink
support now that Jiri Pirko kindly added the ifrastructure).  Default
pvid is assigned to all ports that do not assign their own pvid or
already have a given vlan configured.  This makes it very simple
to enable vlan filtering on the bridge, not have to configure a thing,
and still pass untagged traffic.

The other small thing this series adds is automatic update of the
vlan filter when vlan is configured on top of the bridge.  In this
case we automatically add the given vlan to the bridge filter list.
The ports may still need to be updated as we don't know which ports
are allowed to receive a given vlan.

Thanks
-vlad

Vladislav Yasevich (3):
  bridge: Add a default_pvid sysfs attribute
  bridge: Add filtering support for default_pvid
  bridge; Automatically filter vlans configured on top of bridge

 net/bridge/br_device.c   |  54 +++++++++++++++++++---
 net/bridge/br_if.c       |   2 +
 net/bridge/br_private.h  |  35 ++++++++++++++-
 net/bridge/br_sysfs_br.c |  17 +++++++
 net/bridge/br_vlan.c     | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
 5 files changed, 213 insertions(+), 8 deletions(-)

-- 
1.9.3

[PATCH 1/3] bridge: Add a default_pvid sysfs attribute

[Vladislav Yasevich]

This patch allows the user to set and retrieve default_pvid
value.  A new value can only be stored when vlan filtering
is disabled.

Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
 net/bridge/br_private.h  |  2 ++
 net/bridge/br_sysfs_br.c | 17 +++++++++++++++++
 net/bridge/br_vlan.c     | 28 ++++++++++++++++++++++++++++
 3 files changed, 47 insertions(+)

diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 62a7fa2..84c9a5d 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -299,6 +299,7 @@ struct net_bridge
 #ifdef CONFIG_BRIDGE_VLAN_FILTERING
 	u8				vlan_enabled;
 	__be16				vlan_proto;
+	u16				default_pvid;
 	struct net_port_vlans __rcu	*vlan_info;
 #endif
 };
@@ -602,6 +603,7 @@ void br_recalculate_fwd_mask(struct net_bridge *br);
 int br_vlan_filter_toggle(struct net_bridge *br, unsigned long val);
 int br_vlan_set_proto(struct net_bridge *br, unsigned long val);
 void br_vlan_init(struct net_bridge *br);
+int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val);
 int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags);
 int nbp_vlan_delete(struct net_bridge_port *port, u16 vid);
 void nbp_vlan_flush(struct net_bridge_port *port);
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index c9e2572..b969d9e 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -725,6 +725,22 @@ static ssize_t vlan_protocol_store(struct device *d,
 	return store_bridge_parm(d, buf, len, br_vlan_set_proto);
 }
 static DEVICE_ATTR_RW(vlan_protocol);
+
+static ssize_t default_pvid_show(struct device *d,
+				 struct device_attribute *attr,
+				 char *buf)
+{
+	struct net_bridge *br = to_bridge(d);
+	return sprintf(buf, "%d\n", br->default_pvid);
+}
+
+static ssize_t default_pvid_store(struct device *d,
+				  struct device_attribute *attr,
+				  const char *buf, size_t len)
+{
+	return store_bridge_parm(d, buf, len, br_vlan_set_default_pvid);
+}
+static DEVICE_ATTR_RW(default_pvid);
 #endif
 
 static struct attribute *bridge_attrs[] = {
@@ -771,6 +787,7 @@ static struct attribute *bridge_attrs[] = {
 #ifdef CONFIG_BRIDGE_VLAN_FILTERING
 	&dev_attr_vlan_filtering.attr,
 	&dev_attr_vlan_protocol.attr,
+	&dev_attr_default_pvid.attr,
 #endif
 	NULL
 };
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index e1bcd65..43a297b 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -489,9 +489,37 @@ err_filt:
 	goto unlock;
 }
 
+int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val)
+{
+	u16 pvid = val;
+	int err = 0;
+
+	if (!pvid || pvid >= VLAN_VID_MASK)
+		return -EINVAL;
+
+	if (!rtnl_trylock())
+		return restart_syscall();
+
+	if (pvid == br->default_pvid)
+		goto unlock;
+
+	/* Only allow default pvid change when filtering is disabled */
+	if (br->vlan_enabled) {
+		err = -EPERM;
+		goto unlock;
+	}
+
+	br->default_pvid = vid;
+
+unlock:
+	rtnl_unlock();
+	return err;
+}
+
 void br_vlan_init(struct net_bridge *br)
 {
 	br->vlan_proto = htons(ETH_P_8021Q);
+	br->default_pvid = 1;
 }
 
 /* Must be protected by RTNL.
-- 
1.9.3

[Bridge] [PATCH 1/3] bridge: Add a default_pvid sysfs attribute

[Vladislav Yasevich]

This patch allows the user to set and retrieve default_pvid
value.  A new value can only be stored when vlan filtering
is disabled.

Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
 net/bridge/br_private.h  |  2 ++
 net/bridge/br_sysfs_br.c | 17 +++++++++++++++++
 net/bridge/br_vlan.c     | 28 ++++++++++++++++++++++++++++
 3 files changed, 47 insertions(+)

diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 62a7fa2..84c9a5d 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -299,6 +299,7 @@ struct net_bridge
 #ifdef CONFIG_BRIDGE_VLAN_FILTERING
 	u8				vlan_enabled;
 	__be16				vlan_proto;
+	u16				default_pvid;
 	struct net_port_vlans __rcu	*vlan_info;
 #endif
 };
@@ -602,6 +603,7 @@ void br_recalculate_fwd_mask(struct net_bridge *br);
 int br_vlan_filter_toggle(struct net_bridge *br, unsigned long val);
 int br_vlan_set_proto(struct net_bridge *br, unsigned long val);
 void br_vlan_init(struct net_bridge *br);
+int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val);
 int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags);
 int nbp_vlan_delete(struct net_bridge_port *port, u16 vid);
 void nbp_vlan_flush(struct net_bridge_port *port);
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index c9e2572..b969d9e 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -725,6 +725,22 @@ static ssize_t vlan_protocol_store(struct device *d,
 	return store_bridge_parm(d, buf, len, br_vlan_set_proto);
 }
 static DEVICE_ATTR_RW(vlan_protocol);
+
+static ssize_t default_pvid_show(struct device *d,
+				 struct device_attribute *attr,
+				 char *buf)
+{
+	struct net_bridge *br = to_bridge(d);
+	return sprintf(buf, "%d\n", br->default_pvid);
+}
+
+static ssize_t default_pvid_store(struct device *d,
+				  struct device_attribute *attr,
+				  const char *buf, size_t len)
+{
+	return store_bridge_parm(d, buf, len, br_vlan_set_default_pvid);
+}
+static DEVICE_ATTR_RW(default_pvid);
 #endif
 
 static struct attribute *bridge_attrs[] = {
@@ -771,6 +787,7 @@ static struct attribute *bridge_attrs[] = {
 #ifdef CONFIG_BRIDGE_VLAN_FILTERING
 	&dev_attr_vlan_filtering.attr,
 	&dev_attr_vlan_protocol.attr,
+	&dev_attr_default_pvid.attr,
 #endif
 	NULL
 };
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index e1bcd65..43a297b 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -489,9 +489,37 @@ err_filt:
 	goto unlock;
 }
 
+int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val)
+{
+	u16 pvid = val;
+	int err = 0;
+
+	if (!pvid || pvid >= VLAN_VID_MASK)
+		return -EINVAL;
+
+	if (!rtnl_trylock())
+		return restart_syscall();
+
+	if (pvid == br->default_pvid)
+		goto unlock;
+
+	/* Only allow default pvid change when filtering is disabled */
+	if (br->vlan_enabled) {
+		err = -EPERM;
+		goto unlock;
+	}
+
+	br->default_pvid = vid;
+
+unlock:
+	rtnl_unlock();
+	return err;
+}
+
 void br_vlan_init(struct net_bridge *br)
 {
 	br->vlan_proto = htons(ETH_P_8021Q);
+	br->default_pvid = 1;
 }
 
 /* Must be protected by RTNL.
-- 
1.9.3

[PATCH 2/3] bridge: Add filtering support for default_pvid

[Vladislav Yasevich]

Currently when vlan filtering is turned on on the bridge, the bridge
will drop all traffic untill the user configures the filter.  This
isn't very nice for ports that don't care about vlans and just
want untagged traffic.

A concept of a default_pvid was recently introduced.  This patch
adds filtering support for default_pvid.   Now, ports that don't
care about vlans and don't define there own filter will belong
to the VLAN of the default_pvid and continue to receive untagged
traffic.

Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
 net/bridge/br_device.c  |  8 +++--
 net/bridge/br_if.c      |  2 ++
 net/bridge/br_private.h | 13 ++++++--
 net/bridge/br_vlan.c    | 87 +++++++++++++++++++++++++++++++++++++++++++++++--
 4 files changed, 104 insertions(+), 6 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 568cccd..af8f706 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -88,12 +88,17 @@ out:
 static int br_dev_init(struct net_device *dev)
 {
 	struct net_bridge *br = netdev_priv(dev);
+	int err;
 
 	br->stats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
 	if (!br->stats)
 		return -ENOMEM;
 
-	return 0;
+	err = br_vlan_init(br);
+	if (err)
+		free_percpu(br->stats);
+
+	return err;
 }
 
 static int br_dev_open(struct net_device *dev)
@@ -389,5 +394,4 @@ void br_dev_setup(struct net_device *dev)
 	br_netfilter_rtable_init(br);
 	br_stp_timer_init(br);
 	br_multicast_init(br);
-	br_vlan_init(br);
 }
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index a9f54a9..cb2b20f 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -500,6 +500,8 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
 	if (br_fdb_insert(br, p, dev->dev_addr, 0))
 		netdev_err(dev, "failed insert local address bridge forwarding table\n");
 
+	nbp_vlan_init(p);
+
 	spin_lock_bh(&br->lock);
 	changed_addr = br_stp_recalculate_bridge_id(br);
 
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 84c9a5d..bb4abdf 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -602,12 +602,13 @@ bool br_vlan_find(struct net_bridge *br, u16 vid);
 void br_recalculate_fwd_mask(struct net_bridge *br);
 int br_vlan_filter_toggle(struct net_bridge *br, unsigned long val);
 int br_vlan_set_proto(struct net_bridge *br, unsigned long val);
-void br_vlan_init(struct net_bridge *br);
+int br_vlan_init(struct net_bridge *br);
 int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val);
 int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags);
 int nbp_vlan_delete(struct net_bridge_port *port, u16 vid);
 void nbp_vlan_flush(struct net_bridge_port *port);
 bool nbp_vlan_find(struct net_bridge_port *port, u16 vid);
+int nbp_vlan_init(struct net_bridge_port *port);
 
 static inline struct net_port_vlans *br_get_vlan_info(
 						const struct net_bridge *br)
@@ -640,6 +641,8 @@ static inline int br_vlan_get_tag(const struct sk_buff *skb, u16 *vid)
 
 static inline u16 br_get_pvid(const struct net_port_vlans *v)
 {
+	if (!v)
+		return VLAN_N_VID;
 	/* Return just the VID if it is set, or VLAN_N_VID (invalid vid) if
 	 * vid wasn't set
 	 */
@@ -703,8 +706,9 @@ static inline void br_recalculate_fwd_mask(struct net_bridge *br)
 {
 }
 
-static inline void br_vlan_init(struct net_bridge *br)
+static inline int br_vlan_init(struct net_bridge *br)
 {
+	return 0;
 }
 
 static inline int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
@@ -737,6 +741,11 @@ static inline bool nbp_vlan_find(struct net_bridge_port *port, u16 vid)
 	return false;
 }
 
+static inline int nbp_vlan_init(struct net_bridge_port *port)
+{
+	return 0;
+}
+
 static inline u16 br_vlan_get_tag(const struct sk_buff *skb, u16 *tag)
 {
 	return 0;
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 43a297b..4b807ef 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -489,6 +489,80 @@ err_filt:
 	goto unlock;
 }
 
+static int __br_vlan_set_default_pvid(struct net_bridge *br, u16 pvid)
+{
+	struct net_bridge_port *p;
+	u16 old_pvid;
+	int err;
+	DECLARE_BITMAP(changed, BR_MAX_PORTS);
+
+	bitmap_zero(changed, BR_MAX_PORTS);
+
+	/* This function runs with filtering turned off so we can
+	 * remove the old pvid configuration and add the new one after
+	 * without impacting traffic.
+	 */
+
+	old_pvid = br->default_pvid;
+
+	/* If the user has set a different PVID or if the new default pvid
+	 * conflicts with user configuration, do not modify the configuration.
+	 */
+	if (old_pvid != br_get_pvid(br_get_vlan_info(br)) ||
+	    br_vlan_find(br, pvid))
+		goto do_ports;
+
+	set_bit(0, changed);
+	br_vlan_delete(br, old_pvid);
+	err = br_vlan_add(br, pvid,
+			  BRIDGE_VLAN_INFO_PVID | BRIDGE_VLAN_INFO_UNTAGGED);
+	if (err)
+		goto err_br;
+
+do_ports:
+	list_for_each_entry(p, &br->port_list, list) {
+		/* If the user has set a different PVID or if the new default
+		 * pvid conflicts with user configuration, do not modify the
+		 * configuration.
+		 */
+		if (old_pvid != br_get_pvid(nbp_get_vlan_info(p)) ||
+		    nbp_vlan_find(p, pvid))
+			continue;
+
+		set_bit(p->port_no, changed);
+		err = nbp_vlan_add(p, pvid,
+				   BRIDGE_VLAN_INFO_PVID |
+				   BRIDGE_VLAN_INFO_UNTAGGED);
+		if (err)
+			goto err_port;
+		nbp_vlan_delete(p, old_pvid);
+	}
+
+	br->default_pvid = pvid;
+
+	return 0;
+
+err_port:
+	list_for_each_entry_continue_reverse(p, &br->port_list, list) {
+		if (!test_bit(p->port_no, changed))
+			continue;
+
+		nbp_vlan_delete(p, pvid);
+		nbp_vlan_add(p, old_pvid,
+			     BRIDGE_VLAN_INFO_PVID |
+			     BRIDGE_VLAN_INFO_UNTAGGED);
+	}
+
+err_br:
+	if (test_bit(0, changed)) {
+		br_vlan_delete(br, pvid);
+		br_vlan_add(br, old_pvid,
+			    BRIDGE_VLAN_INFO_PVID |
+			    BRIDGE_VLAN_INFO_UNTAGGED);
+	}
+	return err;
+}
+
 int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val)
 {
 	u16 pvid = val;
@@ -509,17 +583,19 @@ int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val)
 		goto unlock;
 	}
 
-	br->default_pvid = vid;
+	err = __br_vlan_set_default_pvid(br, pvid);
 
 unlock:
 	rtnl_unlock();
 	return err;
 }
 
-void br_vlan_init(struct net_bridge *br)
+int br_vlan_init(struct net_bridge *br)
 {
 	br->vlan_proto = htons(ETH_P_8021Q);
 	br->default_pvid = 1;
+	return br_vlan_add(br, 1,
+			   BRIDGE_VLAN_INFO_PVID | BRIDGE_VLAN_INFO_UNTAGGED);
 }
 
 /* Must be protected by RTNL.
@@ -611,3 +687,10 @@ out:
 	rcu_read_unlock();
 	return found;
 }
+
+int nbp_vlan_init(struct net_bridge_port *p)
+{
+	return nbp_vlan_add(p, p->br->default_pvid,
+			    BRIDGE_VLAN_INFO_PVID |
+			    BRIDGE_VLAN_INFO_UNTAGGED);
+}
-- 
1.9.3

[Bridge] [PATCH 2/3] bridge: Add filtering support for default_pvid

[Vladislav Yasevich]

Currently when vlan filtering is turned on on the bridge, the bridge
will drop all traffic untill the user configures the filter.  This
isn't very nice for ports that don't care about vlans and just
want untagged traffic.

A concept of a default_pvid was recently introduced.  This patch
adds filtering support for default_pvid.   Now, ports that don't
care about vlans and don't define there own filter will belong
to the VLAN of the default_pvid and continue to receive untagged
traffic.

Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
 net/bridge/br_device.c  |  8 +++--
 net/bridge/br_if.c      |  2 ++
 net/bridge/br_private.h | 13 ++++++--
 net/bridge/br_vlan.c    | 87 +++++++++++++++++++++++++++++++++++++++++++++++--
 4 files changed, 104 insertions(+), 6 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 568cccd..af8f706 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -88,12 +88,17 @@ out:
 static int br_dev_init(struct net_device *dev)
 {
 	struct net_bridge *br = netdev_priv(dev);
+	int err;
 
 	br->stats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
 	if (!br->stats)
 		return -ENOMEM;
 
-	return 0;
+	err = br_vlan_init(br);
+	if (err)
+		free_percpu(br->stats);
+
+	return err;
 }
 
 static int br_dev_open(struct net_device *dev)
@@ -389,5 +394,4 @@ void br_dev_setup(struct net_device *dev)
 	br_netfilter_rtable_init(br);
 	br_stp_timer_init(br);
 	br_multicast_init(br);
-	br_vlan_init(br);
 }
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index a9f54a9..cb2b20f 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -500,6 +500,8 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
 	if (br_fdb_insert(br, p, dev->dev_addr, 0))
 		netdev_err(dev, "failed insert local address bridge forwarding table\n");
 
+	nbp_vlan_init(p);
+
 	spin_lock_bh(&br->lock);
 	changed_addr = br_stp_recalculate_bridge_id(br);
 
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 84c9a5d..bb4abdf 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -602,12 +602,13 @@ bool br_vlan_find(struct net_bridge *br, u16 vid);
 void br_recalculate_fwd_mask(struct net_bridge *br);
 int br_vlan_filter_toggle(struct net_bridge *br, unsigned long val);
 int br_vlan_set_proto(struct net_bridge *br, unsigned long val);
-void br_vlan_init(struct net_bridge *br);
+int br_vlan_init(struct net_bridge *br);
 int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val);
 int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags);
 int nbp_vlan_delete(struct net_bridge_port *port, u16 vid);
 void nbp_vlan_flush(struct net_bridge_port *port);
 bool nbp_vlan_find(struct net_bridge_port *port, u16 vid);
+int nbp_vlan_init(struct net_bridge_port *port);
 
 static inline struct net_port_vlans *br_get_vlan_info(
 						const struct net_bridge *br)
@@ -640,6 +641,8 @@ static inline int br_vlan_get_tag(const struct sk_buff *skb, u16 *vid)
 
 static inline u16 br_get_pvid(const struct net_port_vlans *v)
 {
+	if (!v)
+		return VLAN_N_VID;
 	/* Return just the VID if it is set, or VLAN_N_VID (invalid vid) if
 	 * vid wasn't set
 	 */
@@ -703,8 +706,9 @@ static inline void br_recalculate_fwd_mask(struct net_bridge *br)
 {
 }
 
-static inline void br_vlan_init(struct net_bridge *br)
+static inline int br_vlan_init(struct net_bridge *br)
 {
+	return 0;
 }
 
 static inline int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
@@ -737,6 +741,11 @@ static inline bool nbp_vlan_find(struct net_bridge_port *port, u16 vid)
 	return false;
 }
 
+static inline int nbp_vlan_init(struct net_bridge_port *port)
+{
+	return 0;
+}
+
 static inline u16 br_vlan_get_tag(const struct sk_buff *skb, u16 *tag)
 {
 	return 0;
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 43a297b..4b807ef 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -489,6 +489,80 @@ err_filt:
 	goto unlock;
 }
 
+static int __br_vlan_set_default_pvid(struct net_bridge *br, u16 pvid)
+{
+	struct net_bridge_port *p;
+	u16 old_pvid;
+	int err;
+	DECLARE_BITMAP(changed, BR_MAX_PORTS);
+
+	bitmap_zero(changed, BR_MAX_PORTS);
+
+	/* This function runs with filtering turned off so we can
+	 * remove the old pvid configuration and add the new one after
+	 * without impacting traffic.
+	 */
+
+	old_pvid = br->default_pvid;
+
+	/* If the user has set a different PVID or if the new default pvid
+	 * conflicts with user configuration, do not modify the configuration.
+	 */
+	if (old_pvid != br_get_pvid(br_get_vlan_info(br)) ||
+	    br_vlan_find(br, pvid))
+		goto do_ports;
+
+	set_bit(0, changed);
+	br_vlan_delete(br, old_pvid);
+	err = br_vlan_add(br, pvid,
+			  BRIDGE_VLAN_INFO_PVID | BRIDGE_VLAN_INFO_UNTAGGED);
+	if (err)
+		goto err_br;
+
+do_ports:
+	list_for_each_entry(p, &br->port_list, list) {
+		/* If the user has set a different PVID or if the new default
+		 * pvid conflicts with user configuration, do not modify the
+		 * configuration.
+		 */
+		if (old_pvid != br_get_pvid(nbp_get_vlan_info(p)) ||
+		    nbp_vlan_find(p, pvid))
+			continue;
+
+		set_bit(p->port_no, changed);
+		err = nbp_vlan_add(p, pvid,
+				   BRIDGE_VLAN_INFO_PVID |
+				   BRIDGE_VLAN_INFO_UNTAGGED);
+		if (err)
+			goto err_port;
+		nbp_vlan_delete(p, old_pvid);
+	}
+
+	br->default_pvid = pvid;
+
+	return 0;
+
+err_port:
+	list_for_each_entry_continue_reverse(p, &br->port_list, list) {
+		if (!test_bit(p->port_no, changed))
+			continue;
+
+		nbp_vlan_delete(p, pvid);
+		nbp_vlan_add(p, old_pvid,
+			     BRIDGE_VLAN_INFO_PVID |
+			     BRIDGE_VLAN_INFO_UNTAGGED);
+	}
+
+err_br:
+	if (test_bit(0, changed)) {
+		br_vlan_delete(br, pvid);
+		br_vlan_add(br, old_pvid,
+			    BRIDGE_VLAN_INFO_PVID |
+			    BRIDGE_VLAN_INFO_UNTAGGED);
+	}
+	return err;
+}
+
 int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val)
 {
 	u16 pvid = val;
@@ -509,17 +583,19 @@ int br_vlan_set_default_pvid(struct net_bridge *br, unsigned long val)
 		goto unlock;
 	}
 
-	br->default_pvid = vid;
+	err = __br_vlan_set_default_pvid(br, pvid);
 
 unlock:
 	rtnl_unlock();
 	return err;
 }
 
-void br_vlan_init(struct net_bridge *br)
+int br_vlan_init(struct net_bridge *br)
 {
 	br->vlan_proto = htons(ETH_P_8021Q);
 	br->default_pvid = 1;
+	return br_vlan_add(br, 1,
+			   BRIDGE_VLAN_INFO_PVID | BRIDGE_VLAN_INFO_UNTAGGED);
 }
 
 /* Must be protected by RTNL.
@@ -611,3 +687,10 @@ out:
 	rcu_read_unlock();
 	return found;
 }
+
+int nbp_vlan_init(struct net_bridge_port *p)
+{
+	return nbp_vlan_add(p, p->br->default_pvid,
+			    BRIDGE_VLAN_INFO_PVID |
+			    BRIDGE_VLAN_INFO_UNTAGGED);
+}
-- 
1.9.3

[PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vladislav Yasevich]

If the user configures vlan devices on top of the bridge,
automatically set up filter entries for it as long as
bridge vlan protocol matches that of the vlan.
This allows the user to atomatically receive vlan traffic
for the vlans that are convifgured.

Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
 net/bridge/br_device.c  | 46 +++++++++++++++++++++++++++++++++++++++++++---
 net/bridge/br_private.h | 20 ++++++++++++++++++++
 2 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index af8f706..1e8caec 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -307,6 +307,45 @@ static int br_del_slave(struct net_device *dev, struct net_device *slave_dev)
 	return br_del_if(br, slave_dev);
 }
 
+static int br_vlan_rx_add_vid(struct net_device *br_dev,
+			      __be16 proto, u16 vid)
+{
+	struct net_bridge *br = netdev_priv(br_dev);
+
+	if (proto != br_vlan_protocol(br))
+		return 0;
+
+	/* vid 0 is special and will be added by the vlan layer to lower
+	 * devices.  Don't do anything here.
+	 */
+	if (vid == 0)
+		return 0;
+
+	return br_vlan_add(br, vid, 0);
+}
+
+static int br_vlan_rx_kill_vid(struct net_device *br_dev,
+			       __be16 proto, u16 vid)
+{
+	struct net_bridge *br = netdev_priv(br_dev);
+
+	if (proto != br_vlan_protocol(br))
+		return 0;
+
+	/* vid 0 is special and will be removed by the vlan layer from lower
+	 * devices.  Don't do anything here.
+	 */
+	if (vid == 0)
+		return 0;
+
+	/* Don't report error.  This will fail if the vlan was
+	 * previousely remove by some other means and we don't
+	 * wan't to polute the log/bug the user.
+	 */
+	br_vlan_delete(br, vid);
+	return 0;
+}
+
 static const struct ethtool_ops br_ethtool_ops = {
 	.get_drvinfo    = br_getinfo,
 	.get_link	= ethtool_op_get_link,
@@ -337,6 +376,8 @@ static const struct net_device_ops br_netdev_ops = {
 	.ndo_bridge_getlink	 = br_getlink,
 	.ndo_bridge_setlink	 = br_setlink,
 	.ndo_bridge_dellink	 = br_dellink,
+	.ndo_vlan_rx_add_vid	 = br_vlan_rx_add_vid,
+	.ndo_vlan_rx_kill_vid	 = br_vlan_rx_kill_vid,
 };
 
 static void br_dev_free(struct net_device *dev)
@@ -366,9 +407,8 @@ void br_dev_setup(struct net_device *dev)
 	dev->priv_flags = IFF_EBRIDGE;
 
 	dev->features = COMMON_FEATURES | NETIF_F_LLTX | NETIF_F_NETNS_LOCAL |
-			NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
-	dev->hw_features = COMMON_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
-			   NETIF_F_HW_VLAN_STAG_TX;
+			BRIDGE_VLAN_FEATURES;
+	dev->hw_features = COMMON_FEATURES | BRIDGE_VLAN_FEATURES;
 	dev->vlan_features = COMMON_FEATURES;
 
 	br->dev = dev;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index bb4abdf..73a1563 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -29,6 +29,16 @@
 #define BR_MAX_PORTS	(1<<BR_PORT_BITS)
 #define BR_VLAN_BITMAP_LEN	BITS_TO_LONGS(VLAN_N_VID)
 
+#ifdef CONFIG_BRIDGE_VLAN_FILTERING
+#define BRIDGE_VLAN_FEATURES (NETIF_F_HW_VLAN_CTAG_TX | \
+			     NETIF_F_HW_VLAN_CTAG_FILTER | \
+			     NETIF_F_HW_VLAN_STAG_TX | \
+			     NETIF_F_HW_VLAN_STAG_FILTER)
+#else
+#define BRIDGE_VLAN_FEATURES (NETIF_F_HW_VLAN_CTAG_TX | \
+			     NETIF_F_HW_VLAN_STAG_TX)
+#endif
+
 #define BR_VERSION	"2.3"
 
 /* Control of forwarding link local multicast */
@@ -654,6 +664,11 @@ static inline int br_vlan_enabled(struct net_bridge *br)
 {
 	return br->vlan_enabled;
 }
+
+static inline __be16 br_vlan_protocol(struct net_bridge *br)
+{
+	return br->vlan_proto;
+}
 #else
 static inline bool br_allowed_ingress(struct net_bridge *br,
 				      struct net_port_vlans *v,
@@ -759,6 +774,11 @@ static inline int br_vlan_enabled(struct net_bridge *br)
 {
 	return 0;
 }
+
+static inline __be16 br_vlan_protocol(struct net_bridge *br)
+{
+	return 0;
+}
 #endif
 
 /* br_netfilter.c */
-- 
1.9.3

[Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vladislav Yasevich]

If the user configures vlan devices on top of the bridge,
automatically set up filter entries for it as long as
bridge vlan protocol matches that of the vlan.
This allows the user to atomatically receive vlan traffic
for the vlans that are convifgured.

Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
 net/bridge/br_device.c  | 46 +++++++++++++++++++++++++++++++++++++++++++---
 net/bridge/br_private.h | 20 ++++++++++++++++++++
 2 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index af8f706..1e8caec 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -307,6 +307,45 @@ static int br_del_slave(struct net_device *dev, struct net_device *slave_dev)
 	return br_del_if(br, slave_dev);
 }
 
+static int br_vlan_rx_add_vid(struct net_device *br_dev,
+			      __be16 proto, u16 vid)
+{
+	struct net_bridge *br = netdev_priv(br_dev);
+
+	if (proto != br_vlan_protocol(br))
+		return 0;
+
+	/* vid 0 is special and will be added by the vlan layer to lower
+	 * devices.  Don't do anything here.
+	 */
+	if (vid == 0)
+		return 0;
+
+	return br_vlan_add(br, vid, 0);
+}
+
+static int br_vlan_rx_kill_vid(struct net_device *br_dev,
+			       __be16 proto, u16 vid)
+{
+	struct net_bridge *br = netdev_priv(br_dev);
+
+	if (proto != br_vlan_protocol(br))
+		return 0;
+
+	/* vid 0 is special and will be removed by the vlan layer from lower
+	 * devices.  Don't do anything here.
+	 */
+	if (vid == 0)
+		return 0;
+
+	/* Don't report error.  This will fail if the vlan was
+	 * previousely remove by some other means and we don't
+	 * wan't to polute the log/bug the user.
+	 */
+	br_vlan_delete(br, vid);
+	return 0;
+}
+
 static const struct ethtool_ops br_ethtool_ops = {
 	.get_drvinfo    = br_getinfo,
 	.get_link	= ethtool_op_get_link,
@@ -337,6 +376,8 @@ static const struct net_device_ops br_netdev_ops = {
 	.ndo_bridge_getlink	 = br_getlink,
 	.ndo_bridge_setlink	 = br_setlink,
 	.ndo_bridge_dellink	 = br_dellink,
+	.ndo_vlan_rx_add_vid	 = br_vlan_rx_add_vid,
+	.ndo_vlan_rx_kill_vid	 = br_vlan_rx_kill_vid,
 };
 
 static void br_dev_free(struct net_device *dev)
@@ -366,9 +407,8 @@ void br_dev_setup(struct net_device *dev)
 	dev->priv_flags = IFF_EBRIDGE;
 
 	dev->features = COMMON_FEATURES | NETIF_F_LLTX | NETIF_F_NETNS_LOCAL |
-			NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
-	dev->hw_features = COMMON_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
-			   NETIF_F_HW_VLAN_STAG_TX;
+			BRIDGE_VLAN_FEATURES;
+	dev->hw_features = COMMON_FEATURES | BRIDGE_VLAN_FEATURES;
 	dev->vlan_features = COMMON_FEATURES;
 
 	br->dev = dev;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index bb4abdf..73a1563 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -29,6 +29,16 @@
 #define BR_MAX_PORTS	(1<<BR_PORT_BITS)
 #define BR_VLAN_BITMAP_LEN	BITS_TO_LONGS(VLAN_N_VID)
 
+#ifdef CONFIG_BRIDGE_VLAN_FILTERING
+#define BRIDGE_VLAN_FEATURES (NETIF_F_HW_VLAN_CTAG_TX | \
+			     NETIF_F_HW_VLAN_CTAG_FILTER | \
+			     NETIF_F_HW_VLAN_STAG_TX | \
+			     NETIF_F_HW_VLAN_STAG_FILTER)
+#else
+#define BRIDGE_VLAN_FEATURES (NETIF_F_HW_VLAN_CTAG_TX | \
+			     NETIF_F_HW_VLAN_STAG_TX)
+#endif
+
 #define BR_VERSION	"2.3"
 
 /* Control of forwarding link local multicast */
@@ -654,6 +664,11 @@ static inline int br_vlan_enabled(struct net_bridge *br)
 {
 	return br->vlan_enabled;
 }
+
+static inline __be16 br_vlan_protocol(struct net_bridge *br)
+{
+	return br->vlan_proto;
+}
 #else
 static inline bool br_allowed_ingress(struct net_bridge *br,
 				      struct net_port_vlans *v,
@@ -759,6 +774,11 @@ static inline int br_vlan_enabled(struct net_bridge *br)
 {
 	return 0;
 }
+
+static inline __be16 br_vlan_protocol(struct net_bridge *br)
+{
+	return 0;
+}
 #endif
 
 /* br_netfilter.c */
-- 
1.9.3

Re: [PATCH 2/3] bridge: Add filtering support for default_pvid

[Toshiaki Makita]

(14/09/13 (土) 5:44), Vladislav Yasevich wrote:
> Currently when vlan filtering is turned on on the bridge, the bridge
> will drop all traffic untill the user configures the filter.  This
> isn't very nice for ports that don't care about vlans and just
> want untagged traffic.
> 
> A concept of a default_pvid was recently introduced.  This patch
> adds filtering support for default_pvid.   Now, ports that don't
> care about vlans and don't define there own filter will belong
> to the VLAN of the default_pvid and continue to receive untagged
> traffic.

If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
still not be filtered, right?
vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 2/3] bridge: Add filtering support for default_pvid

[Toshiaki Makita]

(14/09/13 (土) 5:44), Vladislav Yasevich wrote:
> Currently when vlan filtering is turned on on the bridge, the bridge
> will drop all traffic untill the user configures the filter.  This
> isn't very nice for ports that don't care about vlans and just
> want untagged traffic.
> 
> A concept of a default_pvid was recently introduced.  This patch
> adds filtering support for default_pvid.   Now, ports that don't
> care about vlans and don't define there own filter will belong
> to the VLAN of the default_pvid and continue to receive untagged
> traffic.

If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
still not be filtered, right?
vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

(14/09/13 (土) 5:44), Vladislav Yasevich wrote:
> If the user configures vlan devices on top of the bridge,
> automatically set up filter entries for it as long as
> bridge vlan protocol matches that of the vlan.
> This allows the user to atomatically receive vlan traffic
> for the vlans that are convifgured.

Changing br->vlan_proto seems to cause inconsistency between vlan
interfaces and filter settings.
Can we automatically change filters when setting vlan_proto?

>
...
> +static int br_vlan_rx_kill_vid(struct net_device *br_dev,
> +			       __be16 proto, u16 vid)
...
> +	/* Don't report error.  This will fail if the vlan was
> +	 * previousely remove by some other means and we don't
> +	 * wan't to polute the log/bug the user.
> +	 */
> +	br_vlan_delete(br, vid);
> +	return 0;
> +}

It might lead to unexpected behaviour, for example,
1. create br0.10
2. set pvid to 10 on br0
3. delete br0.10
Then, pvid will also be cleared?
Something like ref counting is needed?

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 2/3] bridge: Add filtering support for default_pvid

[Vlad Yasevich]

On 09/14/2014 11:21 AM, Toshiaki Makita wrote:
> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>> Currently when vlan filtering is turned on on the bridge, the bridge
>> will drop all traffic untill the user configures the filter.  This
>> isn't very nice for ports that don't care about vlans and just
>> want untagged traffic.
>>
>> A concept of a default_pvid was recently introduced.  This patch
>> adds filtering support for default_pvid.   Now, ports that don't
>> care about vlans and don't define there own filter will belong
>> to the VLAN of the default_pvid and continue to receive untagged
>> traffic.
> 
> If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
> still not be filtered, right?

Right.

> vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?

I can see arguments for both.  Just because the user wishes to set a
different pvid may not always mean that vlan associated with default pvid
shouldn't be filtered.  I think it's at user's discretion.  I hesitate
to do too many things automatically.

-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>> If the user configures vlan devices on top of the bridge,
>> automatically set up filter entries for it as long as
>> bridge vlan protocol matches that of the vlan.
>> This allows the user to atomatically receive vlan traffic
>> for the vlans that are convifgured.
> 
> Changing br->vlan_proto seems to cause inconsistency between vlan
> interfaces and filter settings.
> Can we automatically change filters when setting vlan_proto?
> 

I thought we already do that in br_vlan_set_proto()?  Nothing
here introduces any new kinds of issue with that code.

>>
> ...
>> +static int br_vlan_rx_kill_vid(struct net_device *br_dev,
>> +			       __be16 proto, u16 vid)
> ...
>> +	/* Don't report error.  This will fail if the vlan was
>> +	 * previousely remove by some other means and we don't
>> +	 * wan't to polute the log/bug the user.
>> +	 */
>> +	br_vlan_delete(br, vid);
>> +	return 0;
>> +}
> 
> It might lead to unexpected behaviour, for example,
> 1. create br0.10
> 2. set pvid to 10 on br0
> 3. delete br0.10
> Then, pvid will also be cleared?
> Something like ref counting is needed?

Gah!  The bitmap implementation is really starting to annoy me.  Yes, it's fast, but it
is so restrictive...

We'd need tracking per vlan id and we can't that right now.  OK, this one needs more
thought.  I'll drop it for now.

Thanks
-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>> If the user configures vlan devices on top of the bridge,
>> automatically set up filter entries for it as long as
>> bridge vlan protocol matches that of the vlan.
>> This allows the user to atomatically receive vlan traffic
>> for the vlans that are convifgured.
> 
> Changing br->vlan_proto seems to cause inconsistency between vlan
> interfaces and filter settings.
> Can we automatically change filters when setting vlan_proto?
> 

I thought we already do that in br_vlan_set_proto()?  Nothing
here introduces any new kinds of issue with that code.

>>
> ...
>> +static int br_vlan_rx_kill_vid(struct net_device *br_dev,
>> +			       __be16 proto, u16 vid)
> ...
>> +	/* Don't report error.  This will fail if the vlan was
>> +	 * previousely remove by some other means and we don't
>> +	 * wan't to polute the log/bug the user.
>> +	 */
>> +	br_vlan_delete(br, vid);
>> +	return 0;
>> +}
> 
> It might lead to unexpected behaviour, for example,
> 1. create br0.10
> 2. set pvid to 10 on br0
> 3. delete br0.10
> Then, pvid will also be cleared?
> Something like ref counting is needed?

Gah!  The bitmap implementation is really starting to annoy me.  Yes, it's fast, but it
is so restrictive...

We'd need tracking per vlan id and we can't that right now.  OK, this one needs more
thought.  I'll drop it for now.

Thanks
-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [PATCH 0/3] bridge: Some nice new things for vlan filtering

[Stephen Hemminger]

On Fri, 12 Sep 2014 16:44:48 -0400
Vladislav Yasevich <vyasevich@gmail.com> wrote:

> While working with vlan filtering and non-promisc mode, I've found
> myself wanting untagged traffic to automatically pass through the
> bridge.  So I decided to introduce the concept of a per bridge default
> pvid.  VLAN 1 is used as default pvid by default and can be changed
> by user through sysfs while vlan filtering is off. (I'll be adding netlink
> support now that Jiri Pirko kindly added the ifrastructure).  Default
> pvid is assigned to all ports that do not assign their own pvid or
> already have a given vlan configured.  This makes it very simple
> to enable vlan filtering on the bridge, not have to configure a thing,
> and still pass untagged traffic.
> 
> The other small thing this series adds is automatic update of the
> vlan filter when vlan is configured on top of the bridge.  In this
> case we automatically add the given vlan to the bridge filter list.
> The ports may still need to be updated as we don't know which ports
> are allowed to receive a given vlan.
> 
> Thanks
> -vlad
> 
> Vladislav Yasevich (3):
>   bridge: Add a default_pvid sysfs attribute
>   bridge: Add filtering support for default_pvid
>   bridge; Automatically filter vlans configured on top of bridge
> 
>  net/bridge/br_device.c   |  54 +++++++++++++++++++---
>  net/bridge/br_if.c       |   2 +
>  net/bridge/br_private.h  |  35 ++++++++++++++-
>  net/bridge/br_sysfs_br.c |  17 +++++++
>  net/bridge/br_vlan.c     | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
>  5 files changed, 213 insertions(+), 8 deletions(-)
> 

Please, no special VLAN 1, other equipment has that silliness.

Why is untagged traffic not treated as VLAN 0?

Re: [Bridge] [PATCH 0/3] bridge: Some nice new things for vlan filtering

[Stephen Hemminger]

On Fri, 12 Sep 2014 16:44:48 -0400
Vladislav Yasevich <vyasevich@gmail.com> wrote:

> While working with vlan filtering and non-promisc mode, I've found
> myself wanting untagged traffic to automatically pass through the
> bridge.  So I decided to introduce the concept of a per bridge default
> pvid.  VLAN 1 is used as default pvid by default and can be changed
> by user through sysfs while vlan filtering is off. (I'll be adding netlink
> support now that Jiri Pirko kindly added the ifrastructure).  Default
> pvid is assigned to all ports that do not assign their own pvid or
> already have a given vlan configured.  This makes it very simple
> to enable vlan filtering on the bridge, not have to configure a thing,
> and still pass untagged traffic.
> 
> The other small thing this series adds is automatic update of the
> vlan filter when vlan is configured on top of the bridge.  In this
> case we automatically add the given vlan to the bridge filter list.
> The ports may still need to be updated as we don't know which ports
> are allowed to receive a given vlan.
> 
> Thanks
> -vlad
> 
> Vladislav Yasevich (3):
>   bridge: Add a default_pvid sysfs attribute
>   bridge: Add filtering support for default_pvid
>   bridge; Automatically filter vlans configured on top of bridge
> 
>  net/bridge/br_device.c   |  54 +++++++++++++++++++---
>  net/bridge/br_if.c       |   2 +
>  net/bridge/br_private.h  |  35 ++++++++++++++-
>  net/bridge/br_sysfs_br.c |  17 +++++++
>  net/bridge/br_vlan.c     | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
>  5 files changed, 213 insertions(+), 8 deletions(-)
> 

Please, no special VLAN 1, other equipment has that silliness.

Why is untagged traffic not treated as VLAN 0?

Re: [PATCH 2/3] bridge: Add filtering support for default_pvid

[Toshiaki Makita]

On 2014/09/16 0:09, Vlad Yasevich wrote:
> On 09/14/2014 11:21 AM, Toshiaki Makita wrote:
>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>> Currently when vlan filtering is turned on on the bridge, the bridge
>>> will drop all traffic untill the user configures the filter.  This
>>> isn't very nice for ports that don't care about vlans and just
>>> want untagged traffic.
>>>
>>> A concept of a default_pvid was recently introduced.  This patch
>>> adds filtering support for default_pvid.   Now, ports that don't
>>> care about vlans and don't define there own filter will belong
>>> to the VLAN of the default_pvid and continue to receive untagged
>>> traffic.
>>
>> If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
>> still not be filtered, right?
> 
> Right.
> 
>> vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?
> 
> I can see arguments for both.  Just because the user wishes to set a
> different pvid may not always mean that vlan associated with default pvid
> shouldn't be filtered.  I think it's at user's discretion.  I hesitate
> to do too many things automatically.

On second thought, I agree with you.
It's reasonable that what default_pvid should do is only to set pvid on
adding a bridge/port.

My another concern is how we can disable default_pvid, since this
feature is originally non-existent.

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 2/3] bridge: Add filtering support for default_pvid

[Toshiaki Makita]

On 2014/09/16 0:09, Vlad Yasevich wrote:
> On 09/14/2014 11:21 AM, Toshiaki Makita wrote:
>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>> Currently when vlan filtering is turned on on the bridge, the bridge
>>> will drop all traffic untill the user configures the filter.  This
>>> isn't very nice for ports that don't care about vlans and just
>>> want untagged traffic.
>>>
>>> A concept of a default_pvid was recently introduced.  This patch
>>> adds filtering support for default_pvid.   Now, ports that don't
>>> care about vlans and don't define there own filter will belong
>>> to the VLAN of the default_pvid and continue to receive untagged
>>> traffic.
>>
>> If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
>> still not be filtered, right?
> 
> Right.
> 
>> vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?
> 
> I can see arguments for both.  Just because the user wishes to set a
> different pvid may not always mean that vlan associated with default pvid
> shouldn't be filtered.  I think it's at user's discretion.  I hesitate
> to do too many things automatically.

On second thought, I agree with you.
It's reasonable that what default_pvid should do is only to set pvid on
adding a bridge/port.

My another concern is how we can disable default_pvid, since this
feature is originally non-existent.

Thanks,
Toshiaki Makita

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

On 2014/09/16 0:19, Vlad Yasevich wrote:
> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>> If the user configures vlan devices on top of the bridge,
>>> automatically set up filter entries for it as long as
>>> bridge vlan protocol matches that of the vlan.
>>> This allows the user to atomatically receive vlan traffic
>>> for the vlans that are convifgured.
>>
>> Changing br->vlan_proto seems to cause inconsistency between vlan
>> interfaces and filter settings.
>> Can we automatically change filters when setting vlan_proto?
>>
> 
> I thought we already do that in br_vlan_set_proto()?  Nothing
> here introduces any new kinds of issue with that code.

I'm referring to a case like this:
1. create br0.10 (802.1ad)
2. change br->vlan_proto into 88a8

When creating br0.10 (1), br->vlan_proto is 8100 and different from
protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
After changing br->vlan_proto (2), we might expect vlan 10 is not
filtered on br0, but it will be filtered.

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

On 2014/09/16 0:19, Vlad Yasevich wrote:
> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>> If the user configures vlan devices on top of the bridge,
>>> automatically set up filter entries for it as long as
>>> bridge vlan protocol matches that of the vlan.
>>> This allows the user to atomatically receive vlan traffic
>>> for the vlans that are convifgured.
>>
>> Changing br->vlan_proto seems to cause inconsistency between vlan
>> interfaces and filter settings.
>> Can we automatically change filters when setting vlan_proto?
>>
> 
> I thought we already do that in br_vlan_set_proto()?  Nothing
> here introduces any new kinds of issue with that code.

I'm referring to a case like this:
1. create br0.10 (802.1ad)
2. change br->vlan_proto into 88a8

When creating br0.10 (1), br->vlan_proto is 8100 and different from
protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
After changing br->vlan_proto (2), we might expect vlan 10 is not
filtered on br0, but it will be filtered.

Thanks,
Toshiaki Makita

Re: [PATCH 0/3] bridge: Some nice new things for vlan filtering

[Toshiaki Makita]

On 2014/09/16 1:24, Stephen Hemminger wrote:
> On Fri, 12 Sep 2014 16:44:48 -0400
> Vladislav Yasevich <vyasevich@gmail.com> wrote:
> 
>> While working with vlan filtering and non-promisc mode, I've found
>> myself wanting untagged traffic to automatically pass through the
>> bridge.  So I decided to introduce the concept of a per bridge default
>> pvid.  VLAN 1 is used as default pvid by default and can be changed
>> by user through sysfs while vlan filtering is off. (I'll be adding netlink
>> support now that Jiri Pirko kindly added the ifrastructure).  Default
>> pvid is assigned to all ports that do not assign their own pvid or
>> already have a given vlan configured.  This makes it very simple
>> to enable vlan filtering on the bridge, not have to configure a thing,
>> and still pass untagged traffic.
>>
>> The other small thing this series adds is automatic update of the
>> vlan filter when vlan is configured on top of the bridge.  In this
>> case we automatically add the given vlan to the bridge filter list.
>> The ports may still need to be updated as we don't know which ports
>> are allowed to receive a given vlan.
>>
>> Thanks
>> -vlad
>>
>> Vladislav Yasevich (3):
>>   bridge: Add a default_pvid sysfs attribute
>>   bridge: Add filtering support for default_pvid
>>   bridge; Automatically filter vlans configured on top of bridge
>>
>>  net/bridge/br_device.c   |  54 +++++++++++++++++++---
>>  net/bridge/br_if.c       |   2 +
>>  net/bridge/br_private.h  |  35 ++++++++++++++-
>>  net/bridge/br_sysfs_br.c |  17 +++++++
>>  net/bridge/br_vlan.c     | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
>>  5 files changed, 213 insertions(+), 8 deletions(-)
>>
> 
> Please, no special VLAN 1, other equipment has that silliness.
> 
> Why is untagged traffic not treated as VLAN 0?

I guess it's respecting 802.1Q spec.

  Table 9-2—Reserved VID values

  VID value: 1
  The default PVID value used for classifying frames on ingress through
  a Bridge Port. The PVID value of a Port can be changed by management.

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 0/3] bridge: Some nice new things for vlan filtering

[Toshiaki Makita]

On 2014/09/16 1:24, Stephen Hemminger wrote:
> On Fri, 12 Sep 2014 16:44:48 -0400
> Vladislav Yasevich <vyasevich@gmail.com> wrote:
> 
>> While working with vlan filtering and non-promisc mode, I've found
>> myself wanting untagged traffic to automatically pass through the
>> bridge.  So I decided to introduce the concept of a per bridge default
>> pvid.  VLAN 1 is used as default pvid by default and can be changed
>> by user through sysfs while vlan filtering is off. (I'll be adding netlink
>> support now that Jiri Pirko kindly added the ifrastructure).  Default
>> pvid is assigned to all ports that do not assign their own pvid or
>> already have a given vlan configured.  This makes it very simple
>> to enable vlan filtering on the bridge, not have to configure a thing,
>> and still pass untagged traffic.
>>
>> The other small thing this series adds is automatic update of the
>> vlan filter when vlan is configured on top of the bridge.  In this
>> case we automatically add the given vlan to the bridge filter list.
>> The ports may still need to be updated as we don't know which ports
>> are allowed to receive a given vlan.
>>
>> Thanks
>> -vlad
>>
>> Vladislav Yasevich (3):
>>   bridge: Add a default_pvid sysfs attribute
>>   bridge: Add filtering support for default_pvid
>>   bridge; Automatically filter vlans configured on top of bridge
>>
>>  net/bridge/br_device.c   |  54 +++++++++++++++++++---
>>  net/bridge/br_if.c       |   2 +
>>  net/bridge/br_private.h  |  35 ++++++++++++++-
>>  net/bridge/br_sysfs_br.c |  17 +++++++
>>  net/bridge/br_vlan.c     | 113 ++++++++++++++++++++++++++++++++++++++++++++++-
>>  5 files changed, 213 insertions(+), 8 deletions(-)
>>
> 
> Please, no special VLAN 1, other equipment has that silliness.
> 
> Why is untagged traffic not treated as VLAN 0?

I guess it's respecting 802.1Q spec.

  Table 9-2—Reserved VID values

  VID value: 1
  The default PVID value used for classifying frames on ingress through
  a Bridge Port. The PVID value of a Port can be changed by management.

Thanks,
Toshiaki Makita

Re: [PATCH 2/3] bridge: Add filtering support for default_pvid

[Vlad Yasevich]

On 09/16/2014 07:10 AM, Toshiaki Makita wrote:
> On 2014/09/16 0:09, Vlad Yasevich wrote:
>> On 09/14/2014 11:21 AM, Toshiaki Makita wrote:
>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>> Currently when vlan filtering is turned on on the bridge, the bridge
>>>> will drop all traffic untill the user configures the filter.  This
>>>> isn't very nice for ports that don't care about vlans and just
>>>> want untagged traffic.
>>>>
>>>> A concept of a default_pvid was recently introduced.  This patch
>>>> adds filtering support for default_pvid.   Now, ports that don't
>>>> care about vlans and don't define there own filter will belong
>>>> to the VLAN of the default_pvid and continue to receive untagged
>>>> traffic.
>>>
>>> If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
>>> still not be filtered, right?
>>
>> Right.
>>
>>> vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?
>>
>> I can see arguments for both.  Just because the user wishes to set a
>> different pvid may not always mean that vlan associated with default pvid
>> shouldn't be filtered.  I think it's at user's discretion.  I hesitate
>> to do too many things automatically.
> 
> On second thought, I agree with you.
> It's reasonable that what default_pvid should do is only to set pvid on
> adding a bridge/port.
> 
> My another concern is how we can disable default_pvid, since this
> feature is originally non-existent.

My knee-jerk reaction is to disable it with a value of 0, but I am trying
to think of a way to address Stephen's comment.

The other alternative might be to use any invalid vlan id to disable it.

-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [Bridge] [PATCH 2/3] bridge: Add filtering support for default_pvid

[Vlad Yasevich]

On 09/16/2014 07:10 AM, Toshiaki Makita wrote:
> On 2014/09/16 0:09, Vlad Yasevich wrote:
>> On 09/14/2014 11:21 AM, Toshiaki Makita wrote:
>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>> Currently when vlan filtering is turned on on the bridge, the bridge
>>>> will drop all traffic untill the user configures the filter.  This
>>>> isn't very nice for ports that don't care about vlans and just
>>>> want untagged traffic.
>>>>
>>>> A concept of a default_pvid was recently introduced.  This patch
>>>> adds filtering support for default_pvid.   Now, ports that don't
>>>> care about vlans and don't define there own filter will belong
>>>> to the VLAN of the default_pvid and continue to receive untagged
>>>> traffic.
>>>
>>> If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
>>> still not be filtered, right?
>>
>> Right.
>>
>>> vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?
>>
>> I can see arguments for both.  Just because the user wishes to set a
>> different pvid may not always mean that vlan associated with default pvid
>> shouldn't be filtered.  I think it's at user's discretion.  I hesitate
>> to do too many things automatically.
> 
> On second thought, I agree with you.
> It's reasonable that what default_pvid should do is only to set pvid on
> adding a bridge/port.
> 
> My another concern is how we can disable default_pvid, since this
> feature is originally non-existent.

My knee-jerk reaction is to disable it with a value of 0, but I am trying
to think of a way to address Stephen's comment.

The other alternative might be to use any invalid vlan id to disable it.

-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
> On 2014/09/16 0:19, Vlad Yasevich wrote:
>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>> If the user configures vlan devices on top of the bridge,
>>>> automatically set up filter entries for it as long as
>>>> bridge vlan protocol matches that of the vlan.
>>>> This allows the user to atomatically receive vlan traffic
>>>> for the vlans that are convifgured.
>>>
>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>> interfaces and filter settings.
>>> Can we automatically change filters when setting vlan_proto?
>>>
>>
>> I thought we already do that in br_vlan_set_proto()?  Nothing
>> here introduces any new kinds of issue with that code.
> 
> I'm referring to a case like this:
> 1. create br0.10 (802.1ad)
> 2. change br->vlan_proto into 88a8
> 
> When creating br0.10 (1), br->vlan_proto is 8100 and different from
> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
> After changing br->vlan_proto (2), we might expect vlan 10 is not
> filtered on br0, but it will be filtered.

Ok, I see what you mean.  This one is a bit tough.  Our options are:
 1) Return an error when configuring br0.10.  This might break user-space.  Not good.
 2) Ignore protocol when crating the filter.  This is not good either as the user
    may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
 3) Re-implement .1ad support per-vlan instead of per-bridge.

You see another other alternatives?

-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
> On 2014/09/16 0:19, Vlad Yasevich wrote:
>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>> If the user configures vlan devices on top of the bridge,
>>>> automatically set up filter entries for it as long as
>>>> bridge vlan protocol matches that of the vlan.
>>>> This allows the user to atomatically receive vlan traffic
>>>> for the vlans that are convifgured.
>>>
>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>> interfaces and filter settings.
>>> Can we automatically change filters when setting vlan_proto?
>>>
>>
>> I thought we already do that in br_vlan_set_proto()?  Nothing
>> here introduces any new kinds of issue with that code.
> 
> I'm referring to a case like this:
> 1. create br0.10 (802.1ad)
> 2. change br->vlan_proto into 88a8
> 
> When creating br0.10 (1), br->vlan_proto is 8100 and different from
> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
> After changing br->vlan_proto (2), we might expect vlan 10 is not
> filtered on br0, but it will be filtered.

Ok, I see what you mean.  This one is a bit tough.  Our options are:
 1) Return an error when configuring br0.10.  This might break user-space.  Not good.
 2) Ignore protocol when crating the filter.  This is not good either as the user
    may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
 3) Re-implement .1ad support per-vlan instead of per-bridge.

You see another other alternatives?

-vlad
> 
> Thanks,
> Toshiaki Makita
> 

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

(14/09/16 (火) 22:31), Vlad Yasevich wrote:
> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>> If the user configures vlan devices on top of the bridge,
>>>>> automatically set up filter entries for it as long as
>>>>> bridge vlan protocol matches that of the vlan.
>>>>> This allows the user to atomatically receive vlan traffic
>>>>> for the vlans that are convifgured.
>>>>
>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>> interfaces and filter settings.
>>>> Can we automatically change filters when setting vlan_proto?
>>>>
>>>
>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>> here introduces any new kinds of issue with that code.
>>
>> I'm referring to a case like this:
>> 1. create br0.10 (802.1ad)
>> 2. change br->vlan_proto into 88a8
>>
>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>> filtered on br0, but it will be filtered.
> 
> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>   2) Ignore protocol when crating the filter.  This is not good either as the user
>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>   3) Re-implement .1ad support per-vlan instead of per-bridge.
> 
> You see another other alternatives?

We might be able to configure filterings on changing vlan_proto.
4) Memorize different protocol's filtering requests in
br_vlan_rx_add_vid() and use them when switching vlan_proto.
5) Scan vlan devices on bridge device when changing vlan_proto.

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

(14/09/16 (火) 22:31), Vlad Yasevich wrote:
> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>> If the user configures vlan devices on top of the bridge,
>>>>> automatically set up filter entries for it as long as
>>>>> bridge vlan protocol matches that of the vlan.
>>>>> This allows the user to atomatically receive vlan traffic
>>>>> for the vlans that are convifgured.
>>>>
>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>> interfaces and filter settings.
>>>> Can we automatically change filters when setting vlan_proto?
>>>>
>>>
>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>> here introduces any new kinds of issue with that code.
>>
>> I'm referring to a case like this:
>> 1. create br0.10 (802.1ad)
>> 2. change br->vlan_proto into 88a8
>>
>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>> filtered on br0, but it will be filtered.
> 
> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>   2) Ignore protocol when crating the filter.  This is not good either as the user
>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>   3) Re-implement .1ad support per-vlan instead of per-bridge.
> 
> You see another other alternatives?

We might be able to configure filterings on changing vlan_proto.
4) Memorize different protocol's filtering requests in
br_vlan_rx_add_vid() and use them when switching vlan_proto.
5) Scan vlan devices on bridge device when changing vlan_proto.

Thanks,
Toshiaki Makita

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>> automatically set up filter entries for it as long as
>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>> for the vlans that are convifgured.
>>>>>
>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>> interfaces and filter settings.
>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>
>>>>
>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>> here introduces any new kinds of issue with that code.
>>>
>>> I'm referring to a case like this:
>>> 1. create br0.10 (802.1ad)
>>> 2. change br->vlan_proto into 88a8
>>>
>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>> filtered on br0, but it will be filtered.
>>
>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>
>> You see another other alternatives?
> 
> We might be able to configure filterings on changing vlan_proto.
> 4) Memorize different protocol's filtering requests in
> br_vlan_rx_add_vid() and use them when switching vlan_proto.

If we do this, we might as well take it one small step further and make per-vlan protocol
support.

> 5) Scan vlan devices on bridge device when changing vlan_proto.
> 

The scan could work...  walk the upper devices looking for vlans and add/delete filters
based on the protocol of the vlan devices.

Seems kind of hacky, but let me give this one a try...

-vlad
> Thanks,
> Toshiaki Makita
> 

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>> automatically set up filter entries for it as long as
>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>> for the vlans that are convifgured.
>>>>>
>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>> interfaces and filter settings.
>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>
>>>>
>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>> here introduces any new kinds of issue with that code.
>>>
>>> I'm referring to a case like this:
>>> 1. create br0.10 (802.1ad)
>>> 2. change br->vlan_proto into 88a8
>>>
>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>> filtered on br0, but it will be filtered.
>>
>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>
>> You see another other alternatives?
> 
> We might be able to configure filterings on changing vlan_proto.
> 4) Memorize different protocol's filtering requests in
> br_vlan_rx_add_vid() and use them when switching vlan_proto.

If we do this, we might as well take it one small step further and make per-vlan protocol
support.

> 5) Scan vlan devices on bridge device when changing vlan_proto.
> 

The scan could work...  walk the upper devices looking for vlans and add/delete filters
based on the protocol of the vlan devices.

Seems kind of hacky, but let me give this one a try...

-vlad
> Thanks,
> Toshiaki Makita
> 

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

On 2014/09/17 0:00, Vlad Yasevich wrote:
> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>> automatically set up filter entries for it as long as
>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>> for the vlans that are convifgured.
>>>>>>
>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>> interfaces and filter settings.
>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>
>>>>>
>>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>>> here introduces any new kinds of issue with that code.
>>>>
>>>> I'm referring to a case like this:
>>>> 1. create br0.10 (802.1ad)
>>>> 2. change br->vlan_proto into 88a8
>>>>
>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>> filtered on br0, but it will be filtered.
>>>
>>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>
>>> You see another other alternatives?
>>
>> We might be able to configure filterings on changing vlan_proto.
>> 4) Memorize different protocol's filtering requests in
>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
> 
> If we do this, we might as well take it one small step further and make per-vlan protocol
> support.
> 
>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>
> 
> The scan could work...  walk the upper devices looking for vlans and add/delete filters
> based on the protocol of the vlan devices.
> 
> Seems kind of hacky, but let me give this one a try...

dev->vlan_info->vid_list might be a more appropriate list since
vlan_vid_add() can be called not only by vlan devices.

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

On 2014/09/17 0:00, Vlad Yasevich wrote:
> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>> automatically set up filter entries for it as long as
>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>> for the vlans that are convifgured.
>>>>>>
>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>> interfaces and filter settings.
>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>
>>>>>
>>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>>> here introduces any new kinds of issue with that code.
>>>>
>>>> I'm referring to a case like this:
>>>> 1. create br0.10 (802.1ad)
>>>> 2. change br->vlan_proto into 88a8
>>>>
>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>> filtered on br0, but it will be filtered.
>>>
>>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>
>>> You see another other alternatives?
>>
>> We might be able to configure filterings on changing vlan_proto.
>> 4) Memorize different protocol's filtering requests in
>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
> 
> If we do this, we might as well take it one small step further and make per-vlan protocol
> support.
> 
>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>
> 
> The scan could work...  walk the upper devices looking for vlans and add/delete filters
> based on the protocol of the vlan devices.
> 
> Seems kind of hacky, but let me give this one a try...

dev->vlan_info->vid_list might be a more appropriate list since
vlan_vid_add() can be called not only by vlan devices.

Thanks,
Toshiaki Makita

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/16/2014 08:25 PM, Toshiaki Makita wrote:
> On 2014/09/17 0:00, Vlad Yasevich wrote:
>> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>>> automatically set up filter entries for it as long as
>>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>>> for the vlans that are convifgured.
>>>>>>>
>>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>>> interfaces and filter settings.
>>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>>
>>>>>>
>>>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>>>> here introduces any new kinds of issue with that code.
>>>>>
>>>>> I'm referring to a case like this:
>>>>> 1. create br0.10 (802.1ad)
>>>>> 2. change br->vlan_proto into 88a8
>>>>>
>>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>>> filtered on br0, but it will be filtered.
>>>>
>>>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>>
>>>> You see another other alternatives?
>>>
>>> We might be able to configure filterings on changing vlan_proto.
>>> 4) Memorize different protocol's filtering requests in
>>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
>>
>> If we do this, we might as well take it one small step further and make per-vlan protocol
>> support.
>>
>>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>>
>>
>> The scan could work...  walk the upper devices looking for vlans and add/delete filters
>> based on the protocol of the vlan devices.
>>
>> Seems kind of hacky, but let me give this one a try...
> 
> dev->vlan_info->vid_list might be a more appropriate list since
> vlan_vid_add() can be called not only by vlan devices.

That's private to vlan implementation and I don't think this is a good reason
to expose it.

-vlad

> 
> Thanks,
> Toshiaki Makita
> 

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Vlad Yasevich]

On 09/16/2014 08:25 PM, Toshiaki Makita wrote:
> On 2014/09/17 0:00, Vlad Yasevich wrote:
>> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>>> automatically set up filter entries for it as long as
>>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>>> for the vlans that are convifgured.
>>>>>>>
>>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>>> interfaces and filter settings.
>>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>>
>>>>>>
>>>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>>>> here introduces any new kinds of issue with that code.
>>>>>
>>>>> I'm referring to a case like this:
>>>>> 1. create br0.10 (802.1ad)
>>>>> 2. change br->vlan_proto into 88a8
>>>>>
>>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>>> filtered on br0, but it will be filtered.
>>>>
>>>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>>
>>>> You see another other alternatives?
>>>
>>> We might be able to configure filterings on changing vlan_proto.
>>> 4) Memorize different protocol's filtering requests in
>>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
>>
>> If we do this, we might as well take it one small step further and make per-vlan protocol
>> support.
>>
>>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>>
>>
>> The scan could work...  walk the upper devices looking for vlans and add/delete filters
>> based on the protocol of the vlan devices.
>>
>> Seems kind of hacky, but let me give this one a try...
> 
> dev->vlan_info->vid_list might be a more appropriate list since
> vlan_vid_add() can be called not only by vlan devices.

That's private to vlan implementation and I don't think this is a good reason
to expose it.

-vlad

> 
> Thanks,
> Toshiaki Makita
> 

Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

On 2014/09/17 23:14, Vlad Yasevich wrote:
> On 09/16/2014 08:25 PM, Toshiaki Makita wrote:
>> On 2014/09/17 0:00, Vlad Yasevich wrote:
>>> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>>>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>>>> automatically set up filter entries for it as long as
>>>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>>>> for the vlans that are convifgured.
>>>>>>>>
>>>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>>>> interfaces and filter settings.
>>>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>>>
>>>>>>>
>>>>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>>>>> here introduces any new kinds of issue with that code.
>>>>>>
>>>>>> I'm referring to a case like this:
>>>>>> 1. create br0.10 (802.1ad)
>>>>>> 2. change br->vlan_proto into 88a8
>>>>>>
>>>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>>>> filtered on br0, but it will be filtered.
>>>>>
>>>>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>>>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>>>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>>>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>>>
>>>>> You see another other alternatives?
>>>>
>>>> We might be able to configure filterings on changing vlan_proto.
>>>> 4) Memorize different protocol's filtering requests in
>>>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
>>>
>>> If we do this, we might as well take it one small step further and make per-vlan protocol
>>> support.
>>>
>>>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>>>
>>>
>>> The scan could work...  walk the upper devices looking for vlans and add/delete filters
>>> based on the protocol of the vlan devices.
>>>
>>> Seems kind of hacky, but let me give this one a try...
>>
>> dev->vlan_info->vid_list might be a more appropriate list since
>> vlan_vid_add() can be called not only by vlan devices.
> 
> That's private to vlan implementation and I don't think this is a good reason
> to expose it.

I'm not thinking that scanning directly this list is appropriate.
My point is that vlan layer manages the exact vid list that dev is
required to unfilter and we maybe don't want to manage such lists
redundantly.
We can make APIs to utilize the vid list indirectly.

A simple (but inefficient) way is to make a function like
"bool vlan_has_vid(dev, proto, vid)" and check for all 4094 vids using it.

A possible more efficient way is the one using bitmap. We can make a
function vlan_vids_inuse(dev, proto, bitmap) and get bitmap of vids,
like udp_lib_lport_inuse().

Thanks,
Toshiaki Makita

Re: [Bridge] [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge

[Toshiaki Makita]

On 2014/09/17 23:14, Vlad Yasevich wrote:
> On 09/16/2014 08:25 PM, Toshiaki Makita wrote:
>> On 2014/09/17 0:00, Vlad Yasevich wrote:
>>> On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
>>>> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>>>>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>>>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>>>>> automatically set up filter entries for it as long as
>>>>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>>>>> for the vlans that are convifgured.
>>>>>>>>
>>>>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>>>>> interfaces and filter settings.
>>>>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>>>>
>>>>>>>
>>>>>>> I thought we already do that in br_vlan_set_proto()?  Nothing
>>>>>>> here introduces any new kinds of issue with that code.
>>>>>>
>>>>>> I'm referring to a case like this:
>>>>>> 1. create br0.10 (802.1ad)
>>>>>> 2. change br->vlan_proto into 88a8
>>>>>>
>>>>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>>>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>>>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>>>>> filtered on br0, but it will be filtered.
>>>>>
>>>>> Ok, I see what you mean.  This one is a bit tough.  Our options are:
>>>>>   1) Return an error when configuring br0.10.  This might break user-space.  Not good.
>>>>>   2) Ignore protocol when crating the filter.  This is not good either as the user
>>>>>      may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>>>>>   3) Re-implement .1ad support per-vlan instead of per-bridge.
>>>>>
>>>>> You see another other alternatives?
>>>>
>>>> We might be able to configure filterings on changing vlan_proto.
>>>> 4) Memorize different protocol's filtering requests in
>>>> br_vlan_rx_add_vid() and use them when switching vlan_proto.
>>>
>>> If we do this, we might as well take it one small step further and make per-vlan protocol
>>> support.
>>>
>>>> 5) Scan vlan devices on bridge device when changing vlan_proto.
>>>>
>>>
>>> The scan could work...  walk the upper devices looking for vlans and add/delete filters
>>> based on the protocol of the vlan devices.
>>>
>>> Seems kind of hacky, but let me give this one a try...
>>
>> dev->vlan_info->vid_list might be a more appropriate list since
>> vlan_vid_add() can be called not only by vlan devices.
> 
> That's private to vlan implementation and I don't think this is a good reason
> to expose it.

I'm not thinking that scanning directly this list is appropriate.
My point is that vlan layer manages the exact vid list that dev is
required to unfilter and we maybe don't want to manage such lists
redundantly.
We can make APIs to utilize the vid list indirectly.

A simple (but inefficient) way is to make a function like
"bool vlan_has_vid(dev, proto, vid)" and check for all 4094 vids using it.

A possible more efficient way is the one using bitmap. We can make a
function vlan_vids_inuse(dev, proto, bitmap) and get bitmap of vids,
like udp_lib_lport_inuse().

Thanks,
Toshiaki Makita