[patch net-next] mlxsw: spectrum_switchdev: Allow port enslavement to a VLAN-unaware bridge

From: Ido Schimmel <redacted>

Up until now we only allowed VLAN devices to be put in a VLAN-unaware
bridge, but some users need the ability to enslave physical ports as
well.

This is achieved by mapping the port and VID 1 to the bridge's vFID,
instead of the port and the VID used by the VLAN device.

The above is valid because as long as the port is not enslaved to a
bridge, VID 1 is guaranteed to be configured as PVID and egress
untagged.

Signed-off-by: Ido Schimmel <redacted>
Signed-off-by: Jiri Pirko <redacted>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index f9f53af04fe1..917663adf925 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c

@@ -1882,14 +1882,10 @@ mlxsw_sp_bridge_8021d_port_join(struct mlxsw_sp_bridge_device *bridge_device,
 				struct netlink_ext_ack *extack)
 {
 	struct mlxsw_sp_port_vlan *mlxsw_sp_port_vlan;
+	struct net_device *dev = bridge_port->dev;
 	u16 vid;
 
-	if (!is_vlan_dev(bridge_port->dev)) {
-		NL_SET_ERR_MSG_MOD(extack, "Only VLAN devices can be enslaved to a VLAN-unaware bridge");
-		return -EINVAL;
-	}
-	vid = vlan_dev_vlan_id(bridge_port->dev);
-
+	vid = is_vlan_dev(dev) ? vlan_dev_vlan_id(dev) : 1;
 	mlxsw_sp_port_vlan = mlxsw_sp_port_vlan_find_by_vid(mlxsw_sp_port, vid);
 	if (WARN_ON(!mlxsw_sp_port_vlan))
 		return -EINVAL;

@@ -1912,8 +1908,10 @@ mlxsw_sp_bridge_8021d_port_leave(struct mlxsw_sp_bridge_device *bridge_device,
 				 struct mlxsw_sp_port *mlxsw_sp_port)
 {
 	struct mlxsw_sp_port_vlan *mlxsw_sp_port_vlan;
-	u16 vid = vlan_dev_vlan_id(bridge_port->dev);
+	struct net_device *dev = bridge_port->dev;
+	u16 vid;
 
+	vid = is_vlan_dev(dev) ? vlan_dev_vlan_id(dev) : 1;
 	mlxsw_sp_port_vlan = mlxsw_sp_port_vlan_find_by_vid(mlxsw_sp_port, vid);
 	if (WARN_ON(!mlxsw_sp_port_vlan))
 		return;

-- 
2.14.3

On 2/20/18 12:45 AM, Jiri Pirko wrote:

From: Ido Schimmel <redacted>

Up until now we only allowed VLAN devices to be put in a VLAN-unaware
bridge, but some users need the ability to enslave physical ports as
well.

This is achieved by mapping the port and VID 1 to the bridge's vFID,
instead of the port and the VID used by the VLAN device.

The above is valid because as long as the port is not enslaved to a
bridge, VID 1 is guaranteed to be configured as PVID and egress
untagged.

Signed-off-by: Ido Schimmel <redacted>
Signed-off-by: Jiri Pirko <redacted>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

Maybe I am missing something in the setup, but I am not getting
host-to-host connectivity. I booted a switch with this patch, configured
a bridge:

# ip a sh dev br0
44: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
    link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff
    inet6 3000:1000:1000:1000::1/80 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::7efe:90ff:fee8:3a79/64 scope link
       valid_lft forever preferred_lft forever

Connected ports:
# ip li sh master br0
36: swp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7d brd ff:ff:ff:ff:ff:ff
37: swp1s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7e brd ff:ff:ff:ff:ff:ff
38: swp1s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7f brd ff:ff:ff:ff:ff:ff
39: swp1s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:80 brd ff:ff:ff:ff:ff:ff
40: swp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff
41: swp3s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7a brd ff:ff:ff:ff:ff:ff
42: swp3s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7b brd ff:ff:ff:ff:ff:ff
43: swp3s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7c brd ff:ff:ff:ff:ff:ff

The switch can see the hosts:
# net show lldp

LocalPort    Speed    Mode       RemotePort    RemoteHost
             Summary
-----------  -------  ---------  ------------
-------------------------------------  -----------------------
eth0         1G       Mgmt       swp37
pioneerMS16.mvlab.cumulusnetworks.com  IP: 10.0.3.155/22(DHCP)
swp1s0       10G      Access/L2  swp1          host1
             Untagged: br0
swp1s1       10G      Access/L2  swp1          host2
             Untagged: br0
swp1s2       10G      Access/L2  swp1          host3
             Untagged: br0
swp1s3       10G      Access/L2  swp1          host4
             Untagged: br0
swp3s0       10G      Access/L2  swp1          host5
             Untagged: br0
swp3s1       10G      Access/L2  swp1          host6
             Untagged: br0
swp3s2       10G      Access/L2  swp1          host7
             Untagged: br0
swp3s3       10G      Access/L2  swp1          host8
             Untagged: br0

and can talk to the hosts:
# ping6 ff02::2%br0
PING ff02::2%br0(ff02::2) 56 data bytes
64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!)
64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!)
64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!)
64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!)
64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!)
64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!)
64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!)
64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!)

but the hosts can not talk to each other:

cumulus@host3:~$ net show lldp

LocalPort  Speed  Mode          RemoteHost   RemotePort
---------  -----  ------------  -----------  ----------
swp1       10G    Interface/L3  mlx-2700-05  swp1s2

cumulus@host3:~$ ping6 3000:1000:1000:1000::2
PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes
^C

--- 3000:1000:1000:1000::2 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 1999ms

On Wed, Feb 21, 2018 at 11:16:35AM -0700, David Ahern wrote:

On 2/20/18 12:45 AM, Jiri Pirko wrote:

quoted

From: Ido Schimmel <redacted>

Up until now we only allowed VLAN devices to be put in a VLAN-unaware
bridge, but some users need the ability to enslave physical ports as
well.

This is achieved by mapping the port and VID 1 to the bridge's vFID,
instead of the port and the VID used by the VLAN device.

The above is valid because as long as the port is not enslaved to a
bridge, VID 1 is guaranteed to be configured as PVID and egress
untagged.

Signed-off-by: Ido Schimmel <redacted>
Signed-off-by: Jiri Pirko <redacted>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

Maybe I am missing something in the setup, but I am not getting
host-to-host connectivity. I booted a switch with this patch, configured
a bridge:

# ip a sh dev br0
44: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
    link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff
    inet6 3000:1000:1000:1000::1/80 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::7efe:90ff:fee8:3a79/64 scope link
       valid_lft forever preferred_lft forever

Connected ports:
# ip li sh master br0
36: swp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7d brd ff:ff:ff:ff:ff:ff
37: swp1s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7e brd ff:ff:ff:ff:ff:ff
38: swp1s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7f brd ff:ff:ff:ff:ff:ff
39: swp1s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:80 brd ff:ff:ff:ff:ff:ff
40: swp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff
41: swp3s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7a brd ff:ff:ff:ff:ff:ff
42: swp3s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7b brd ff:ff:ff:ff:ff:ff
43: swp3s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 7c:fe:90:e8:3a:7c brd ff:ff:ff:ff:ff:ff

The switch can see the hosts:
# net show lldp

LocalPort    Speed    Mode       RemotePort    RemoteHost
             Summary
-----------  -------  ---------  ------------
-------------------------------------  -----------------------
eth0         1G       Mgmt       swp37
pioneerMS16.mvlab.cumulusnetworks.com  IP: 10.0.3.155/22(DHCP)
swp1s0       10G      Access/L2  swp1          host1
             Untagged: br0
swp1s1       10G      Access/L2  swp1          host2
             Untagged: br0
swp1s2       10G      Access/L2  swp1          host3
             Untagged: br0
swp1s3       10G      Access/L2  swp1          host4
             Untagged: br0
swp3s0       10G      Access/L2  swp1          host5
             Untagged: br0
swp3s1       10G      Access/L2  swp1          host6
             Untagged: br0
swp3s2       10G      Access/L2  swp1          host7
             Untagged: br0
swp3s3       10G      Access/L2  swp1          host8
             Untagged: br0

LLDP packets are trapped before L2 forwarding, which can explain why
LLDP works but forwarding doesn't.

and can talk to the hosts:
# ping6 ff02::2%br0

Can you try ff02::1 ?

Can you please try

# brctl showstp br0

To make sure STP state is set to forwarding?

Does it matter if you try IPv4 ping or if vlan_filtering is set 1?
Unfortunately, I can't reproduce on my switch.

Thanks for testing, David!

On 2/21/18 12:25 PM, Ido Schimmel wrote:

quoted

and can talk to the hosts:
# ping6 ff02::2%br0

Can you try ff02::1 ?

same result.

quoted

PING ff02::2%br0(ff02::2) 56 data bytes
64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!)
64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!)
64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!)
64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!)
64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!)
64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!)
64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!)
64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!)

but the hosts can not talk to each other:

cumulus@host3:~$ net show lldp

LocalPort  Speed  Mode          RemoteHost   RemotePort
---------  -----  ------------  -----------  ----------
swp1       10G    Interface/L3  mlx-2700-05  swp1s2

cumulus@host3:~$ ping6 3000:1000:1000:1000::2
PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes
^C

--- 3000:1000:1000:1000::2 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Can you please try

# brctl showstp br0

To make sure STP state is set to forwarding?

it is.

Does it matter if you try IPv4 ping or if vlan_filtering is set 1?
Unfortunately, I can't reproduce on my switch.

Bring up the hosts and then reboot the switch. At that point I get no
host to host communication. As soon as I flap the port on host1 host3 to
host1 starts working.

So it seems to be something about the initial boot state.

On Wed, Feb 21, 2018 at 12:41:39PM -0700, David Ahern wrote:

On 2/21/18 12:25 PM, Ido Schimmel wrote:

quoted

quoted

and can talk to the hosts:
# ping6 ff02::2%br0

Can you try ff02::1 ?

same result.

quoted

quoted

PING ff02::2%br0(ff02::2) 56 data bytes
64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!)
64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!)
64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!)
64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!)
64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!)
64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!)
64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!)
64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!)

but the hosts can not talk to each other:

cumulus@host3:~$ net show lldp

LocalPort  Speed  Mode          RemoteHost   RemotePort
---------  -----  ------------  -----------  ----------
swp1       10G    Interface/L3  mlx-2700-05  swp1s2

cumulus@host3:~$ ping6 3000:1000:1000:1000::2
PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes
^C

--- 3000:1000:1000:1000::2 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Can you please try

# brctl showstp br0

To make sure STP state is set to forwarding?

it is.

quoted

Does it matter if you try IPv4 ping or if vlan_filtering is set 1?
Unfortunately, I can't reproduce on my switch.

Bring up the hosts and then reboot the switch. At that point I get no
host to host communication. As soon as I flap the port on host1 host3 to
host1 starts working.

So it seems to be something about the initial boot state.

You didn't have IPv6 *and* IPv4 ping? I'm asking because it's possible
host1 sent an MLD join to the Solicited-node multicast address before
the bridge started listening, which means it didn't have a corresponding
MDB entry.

Assuming your hosts aren't functioning as multicast routers and sending
MLD queries and that you didn't configure them as mrouter ports on the
switch, then when host3 sent a neighbour solicitation message to host1's
Solicited-node multicast address it wasn't flooded to host3 which
prevented ping from passing.

This also explains why it started working when you flapped the port on
host1, as Linux generates MLD joins in these cases.

You can try to disable snooping:

# ip link set dev br0 type bridge mcast_snooping 0

Just a guess, but worth a try.

Thanks!

On 2/21/18 1:24 PM, Ido Schimmel wrote:

quoted

quoted

Does it matter if you try IPv4 ping or if vlan_filtering is set 1?
Unfortunately, I can't reproduce on my switch.

Bring up the hosts and then reboot the switch. At that point I get no
host to host communication. As soon as I flap the port on host1 host3 to
host1 starts working.

So it seems to be something about the initial boot state.

You didn't have IPv6 *and* IPv4 ping? I'm asking because it's possible
host1 sent an MLD join to the Solicited-node multicast address before
the bridge started listening, which means it didn't have a corresponding
MDB entry.

The sim only configures IPv6, but it is not acting as an mcast router.
It's really a dummy setup -- bridge on the switch, ports connected to hosts.

Assuming your hosts aren't functioning as multicast routers and sending
MLD queries and that you didn't configure them as mrouter ports on the
switch, then when host3 sent a neighbour solicitation message to host1's
Solicited-node multicast address it wasn't flooded to host3 which
prevented ping from passing.

This also explains why it started working when you flapped the port on
host1, as Linux generates MLD joins in these cases.

You can try to disable snooping:

# ip link set dev br0 type bridge mcast_snooping 0

Just a guess, but worth a try.

good guess. That change gets it working.

From: David Ahern <redacted>
Date: Wed, 21 Feb 2018 11:16:35 -0700

On 2/20/18 12:45 AM, Jiri Pirko wrote:

quoted

From: Ido Schimmel <redacted>

Up until now we only allowed VLAN devices to be put in a VLAN-unaware
bridge, but some users need the ability to enslave physical ports as
well.

This is achieved by mapping the port and VID 1 to the bridge's vFID,
instead of the port and the VID used by the VLAN device.

The above is valid because as long as the port is not enslaved to a
bridge, VID 1 is guaranteed to be configured as PVID and egress
untagged.

Signed-off-by: Ido Schimmel <redacted>
Signed-off-by: Jiri Pirko <redacted>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

Maybe I am missing something in the setup, but I am not getting
host-to-host connectivity. I booted a switch with this patch, configured
a bridge:

I'm waiting for this discussion to be fully resolved before applying this
patch.  Just FYI...

On 2/22/18 11:58 AM, David Miller wrote:

From: David Ahern <redacted>
Date: Wed, 21 Feb 2018 11:16:35 -0700

quoted

On 2/20/18 12:45 AM, Jiri Pirko wrote:

quoted

From: Ido Schimmel <redacted>

Up until now we only allowed VLAN devices to be put in a VLAN-unaware
bridge, but some users need the ability to enslave physical ports as
well.

This is achieved by mapping the port and VID 1 to the bridge's vFID,
instead of the port and the VID used by the VLAN device.

The above is valid because as long as the port is not enslaved to a
bridge, VID 1 is guaranteed to be configured as PVID and egress
untagged.

Signed-off-by: Ido Schimmel <redacted>
Signed-off-by: Jiri Pirko <redacted>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

Maybe I am missing something in the setup, but I am not getting
host-to-host connectivity. I booted a switch with this patch, configured
a bridge:

I'm waiting for this discussion to be fully resolved before applying this
patch.  Just FYI...

Ido:

IPv4 works at boot; IPv6 requires the mcast snooping disable. For this
vlan-unaware bridges can that be set automatically?

And then, what are the options for lldp?

On Thu, Feb 22, 2018 at 12:27:35PM -0700, David Ahern wrote:

Ido:

IPv4 works at boot; IPv6 requires the mcast snooping disable. For this
vlan-unaware bridges can that be set automatically?

Can you please try the following patch?

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
index bbd238e50f05..54262af4e98f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c

@@ -112,11 +112,11 @@ static const int mlxsw_sp_sfgc_bc_packet_types[MLXSW_REG_SFGC_TYPE_MAX] = {
 	[MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_NON_IP]	= 1,
 	[MLXSW_REG_SFGC_TYPE_IPV4_LINK_LOCAL]			= 1,
 	[MLXSW_REG_SFGC_TYPE_IPV6_ALL_HOST]			= 1,
+	[MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_IPV6]	= 1,
 };
 
 static const int mlxsw_sp_sfgc_mc_packet_types[MLXSW_REG_SFGC_TYPE_MAX] = {
 	[MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_IPV4]	= 1,
-	[MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_IPV6]	= 1,
 };
 
 static const int *mlxsw_sp_packet_type_sfgc_types[] = {

It should fix your problem.

The real problem that I can then address in net-next is the fact that
the Linux bridge tries to be smart and only resorts to flooding
unregistered multicast packets in case its querier is disabled and in
case it didn't detect any other querier in the network. This isn't
currently reflected to underlying drivers. Only mcast snooping on/off.

Anyway, it's not related to the patch in question. You'd get the same
behavior with VLAN-aware bridges.

And then, what are the options for lldp?

Didn't understand the question. Can you clarify?

On 2/22/18 1:55 PM, Ido Schimmel wrote:

On Thu, Feb 22, 2018 at 12:27:35PM -0700, David Ahern wrote:

quoted

Ido:

IPv4 works at boot; IPv6 requires the mcast snooping disable. For this
vlan-unaware bridges can that be set automatically?

Can you please try the following patch?

...

It should fix your problem.

it does.

The real problem that I can then address in net-next is the fact that
the Linux bridge tries to be smart and only resorts to flooding
unregistered multicast packets in case its querier is disabled and in
case it didn't detect any other querier in the network. This isn't
currently reflected to underlying drivers. Only mcast snooping on/off.

Anyway, it's not related to the patch in question. You'd get the same
behavior with VLAN-aware bridges.

quoted

And then, what are the options for lldp?

Didn't understand the question. Can you clarify?

nm. mental lapse.

Hi Dave,

On Thu, Feb 22, 2018 at 01:58:39PM -0500, David Miller wrote:

I'm waiting for this discussion to be fully resolved before applying this
patch.  Just FYI...

I have a fix for the issue David reported, but it is not related to this
patch (problem manifests itself with VLAN-aware bridges as well).

On 2/20/18 12:45 AM, Jiri Pirko wrote:

From: Ido Schimmel <redacted>

Up until now we only allowed VLAN devices to be put in a VLAN-unaware
bridge, but some users need the ability to enslave physical ports as
well.

This is achieved by mapping the port and VID 1 to the bridge's vFID,
instead of the port and the VID used by the VLAN device.

The above is valid because as long as the port is not enslaved to a
bridge, VID 1 is guaranteed to be configured as PVID and egress
untagged.

Signed-off-by: Ido Schimmel <redacted>
Signed-off-by: Jiri Pirko <redacted>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

Tested-by: David Ahern <redacted>

From: Ido Schimmel <redacted>
Date: Mon, 26 Feb 2018 08:54:33 +0200

Hi Dave,

On Thu, Feb 22, 2018 at 01:58:39PM -0500, David Miller wrote:

quoted

I'm waiting for this discussion to be fully resolved before applying this
patch.  Just FYI...

I have a fix for the issue David reported, but it is not related to this
patch (problem manifests itself with VLAN-aware bridges as well).

Ok, I've applied this patch to net-next then.

Thank you.