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  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]
Date:   Tue, 08 Dec 2020 15:47:25 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     idosch@...sch.org
Cc:     netdev@...r.kernel.org, kuba@...nel.org, jiri@...dia.com,
        petrm@...dia.com, amcohen@...dia.com, mlxsw@...dia.com,
        idosch@...dia.com
Subject: Re: [PATCH net-next 00/13] mlxsw: Add support for Q-in-VNI

From: Ido Schimmel <idosch@...sch.org>
Date: Tue,  8 Dec 2020 11:22:40 +0200

> From: Ido Schimmel <idosch@...dia.com>
> 
> This patch set adds support for Q-in-VNI over Spectrum-{2,3} ASICs.
> Q-in-VNI is like regular VxLAN encapsulation with the sole difference
> that overlay packets can contain a VLAN tag. In Linux, this is achieved
> by adding the VxLAN device to a 802.1ad bridge instead of a 802.1q
> bridge.
> 
> From mlxsw perspective, Q-in-VNI support entails two main changes:
> 
> 1. An outer VLAN tag should always be pushed to the overlay packet
> during decapsulation
> 
> 2. The EtherType used during decapsulation should be 802.1ad (0x88a8)
> instead of the default 802.1q (0x8100)
> 
> Patch set overview:
> 
> Patches #1-#3 add required device registers and fields
> 
> Patch #4 performs small refactoring to allow code re-use
> 
> Patches #5-#7 make the EtherType used during decapsulation a property of
> the tunnel port (i.e., VxLAN). This leads to the driver vetoing
> configurations in which VxLAN devices are member in both 802.1ad and
> 802.1q/802.1d bridges. Will be handled in the future by determining the
> overlay EtherType on the egress port instead
> 
> Patch #8 adds support for Q-in-VNI for Spectrum-2 and newer ASICs
> 
> Patches #9-#10 veto Q-in-VNI for Spectrum-1 ASICs due to some hardware
> limitations. Can be worked around, but decided not to support it for now
> 
> Patch #11 adjusts mlxsw to stop vetoing addition of VXLAN devices to
> 802.1ad bridges
> 
> Patch #12 adds a generic forwarding test that can be used with both veth
> pairs and physical ports with a loopback
> 
> Patch #13 adds a test to make sure mlxsw vetoes unsupported Q-in-VNI
> configurations

Series applied, thank you.

Powered by blists - more mailing lists