+Ido,
On 9/10/2020 8:07 AM, Vladimir Oltean wrote:
Florian, can you please reiterate what is the problem with calling
vlan_vid_add() with a VLAN that is installed by the bridge?
The effect of vlan_vid_add(), to my knowledge, is that the network
interface should add this VLAN to its filtering table, and not drop it.
So why return -EBUSY?
I suppose that if you wanted to have an 802.1Q just for the sake of
receiving VLAN tagged frames but not have them ingress the to the CPU,
you could install an 802.1Q upper, but why would you do that unless the
CPU should also receive that traffic?
The case that I wanted to cover was to avoid the two programming
interfaces or the same VLAN, and prefer the bridge VLAN management over
the 802.1Q upper, because once the switch port is in a bridge, that is
what an user would expect to use.
If you have a bridge that is VLAN aware, it will manage the data and
control path for us and that is all good since it is capable of dealing
with VLAN tagged frames.
A non-VLAN aware bridge's data path is only allowed to see untagged
traffic, so if you wanted somehow to inject untagged traffic into the
bridge data path, then you would add a 802.1Q upper to that switch port,
and somehow add that device into the bridge. There is a problem with
that though, if you have mutliple bridge devices spanning the same
switch, and you do the same thing on another switch port, with another
802.1Q upper, I believe you could break isolation between bridges for
that particular VID.
Most of this was based on discussions we had with Ido and him explaining
to me how they were doing it in mlxsw.
AFAIR the other case which is that you already have a 802.1Q upper, and
then you add the switch port to the bridge is permitted and the bridge
would inherit the VLAN into its local database.
I did not put much thoughts back then into a cascading set-up, so some
assumptions can certainly be broken, and in fact, are broken today as
you experimented.
--
Florian
