Merge branch 'mlxsw-Two-usability-improvements'
authorDavid S. Miller <davem@davemloft.net>
Thu, 20 Dec 2018 23:48:55 +0000 (15:48 -0800)
committerDavid S. Miller <davem@davemloft.net>
Thu, 20 Dec 2018 23:48:55 +0000 (15:48 -0800)
commitc337680fc1f43a5e184099ee8784c868244f02e7
tree0d284656b1d2f8431911e6167d9c94f1af93f451
parent6eea2db21012b287f880edeeffc42f49c3a057d7
parent03a84ea3d8c537f04b862972e2132dff86a4e93d
Merge branch 'mlxsw-Two-usability-improvements'

Ido Schimmel says:

====================
mlxsw: Two usability improvements

This patchset contains two small improvements in the mlxsw driver. The
first one, in patches #1-#2, relieves the user from the need to
configure a VLAN interface and only later the corresponding VXLAN
tunnel. The issue is explained in detail in the first patch.

The second improvement is described below and allows the user to make
use of VID 1 by having the driver use the reserved 4095 VID for untagged
traffic.

VLAN entries on a given port can be associated with either a bridge or a
router. For example, if swp1.10 is assigned an IP address and swp1.20 is
enslaved to a VLAN-unaware bridge, then both {Port 1, VID 10} and {Port
1, VID 20} would be associated with a filtering identifier (FID) of the
correct type.

In case swp1 itself is assigned an IP address or enslaved to a
VLAN-unaware bridge, then a FID would be associated with {Port 1, VID
1}. Using VID 1 for this purpose means that VLAN devices with VID 1
cannot be created over mlxsw ports, as this VID is (ab)used as the
default VLAN.

Instead of using VID 1 for this purpose, we can use VID 4095 which is
reserved for internal use and cannot be configured by either the 8021q
or the bridge driver.

Patches #3-#7 perform small and non-functional changes that finally
allow us to switch to VID 4095 as the default VID in patch #8.

Patch #9 removes the limitation about creation of VLAN devices with VID
1 over mlxsw ports.

Patches #10-#11 add test cases.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>