netdev - Re: [PATCH net-next 0/5] mlxsw: Prepare for VLAN-aware bridge w/VxLAN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20181127.152804.2031133902968113907.davem@davemloft.net>
Date:   Tue, 27 Nov 2018 15:28:04 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     idosch@...lanox.com
Cc:     netdev@...r.kernel.org, jiri@...lanox.com, petrm@...lanox.com,
        mlxsw@...lanox.com
Subject: Re: [PATCH net-next 0/5] mlxsw: Prepare for VLAN-aware bridge
 w/VxLAN

From: Ido Schimmel <idosch@...lanox.com>
Date: Sun, 25 Nov 2018 09:43:53 +0000

> The driver is using 802.1Q filtering identifiers (FIDs) to represent the
> different VLANs in the VLAN-aware bridge (only one is supported).
> 
> However, the device cannot assign a VNI to such FIDs, which prevents the
> driver from supporting the enslavement of VxLAN devices to the
> VLAN-aware bridge.
> 
> This patchset works around this limitation by emulating 802.1Q FIDs
> using 802.1D FIDs, which can be assigned a VNI and so far have only been
> used in conjunction with VLAN-unaware bridges.
> 
> The downside of this approach is that multiple {Port,VID}->FID entries
> are required, whereas a single VID->FID entry is required with "true"
> 802.1Q FIDs.
> 
> First four patches introduce the new FID family of emulated 802.1Q FIDs
> and the associated type of router interfaces (RIFs). Last patch flips
> the driver to use this new FID family.
> 
> The diff is relatively small because the internal implementation of each
> FID family is contained and hidden in spectrum_fid.c. Different internal
> users (e.g., bridge, router) are aware of the different FID types, but
> do not care about their internal implementation. This makes it trivial
> to swap the current implementation of 802.1Q FIDs with the new one,
> using 802.1D FIDs.

Series applied, thanks Ido.