netdev - [PATCH net-next 00/13] mlxsw: Unified bridge conversion

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-next>] [day] [month] [year] [list]

Date:   Sun, 19 Jun 2022 13:29:08 +0300
From:   Ido Schimmel <idosch@...dia.com>
To:     netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
        edumazet@...gle.com, petrm@...dia.com, amcohen@...dia.com,
        mlxsw@...dia.com, Ido Schimmel <idosch@...dia.com>
Subject: [PATCH net-next 00/13] mlxsw: Unified bridge conversion - part 1/6

This set starts converting mlxsw to the unified bridge model and mainly
adds new device registers and extends existing ones that will be used in
follow-up patchsets.

High-level summary
==================

The unified bridge model is a new way of managing low-level device
objects such as filtering identifiers (FIDs). The conversion moves a lot
of logic out of the device's firmware towards the driver, but its main
selling point is that it allows to overcome various scalability issues
related to the amount of entries that need to be programmed to the
device.

The only (intended) user visible changes of the conversion are
improvement in resource utilization and ability to support more router
interfaces (RIFs) in Spectrum-{2,3}.

Details
=======

Commit 50853808ff4a ("Merge branch
'mlxsw-Prepare-for-VLAN-aware-bridge-w-VxLAN'") converted mlxsw to
emulate 802.1Q FIDs (represent VLANs in a VLAN-aware bridge) using
802.1D FIDs (represent VLAN-unaware bridges). This was necessary because
at that time VNI could not be assigned to 802.1Q FIDs, which effectively
meant that mlxsw could not support VXLAN with VLAN-aware bridges.

The downside of this approach is that multiple {Port,VID}->FID entries
are required in order to classify incoming traffic to a FID, as opposed
to a single VID->FID entry that can be used with actual 802.1Q FIDs.

For example, if 10 ports are members in the same VLAN-aware bridge and
the same 100 VLANs are configured on each port, then only 100 VID->FID
entries are required with 802.1Q FIDs, whereas 1000 {Port,VID}->FID
entries are required with emulated 802.1Q FIDs.

The above limitation is the result of various assumptions that were made
in the design of the API that was exposed to software. In the unified
bridge model the API is much more "raw" and therefore avoids these
assumptions, allowing software to configure the device in a more
efficient manner.

Amit Cohen (13):
  mlxsw: reg: Add 'flood_rsp' field to SFMR register
  mlxsw: reg: Add ingress RIF related fields to SFMR register
  mlxsw: reg: Add ingress RIF related fields to SVFA register
  mlxsw: reg: Add Switch Multicast Port to Egress VID Register
  mlxsw: Add SMPE related fields to SMID2 register
  mlxsw: reg: Add SMPE related fields to SFMR register
  mlxsw: reg: Add VID related fields to SFD register
  mlxsw: reg: Add flood related field to SFMR register
  mlxsw: reg: Replace MID related fields in SFGC register
  mlxsw: reg: Add Router Egress Interface to VID Register
  mlxsw: reg: Add egress FID field to RITR register
  mlxsw: Add support for egress FID classification after decapsulation
  mlxsw: reg: Add support for VLAN RIF as part of RITR register

 drivers/net/ethernet/mellanox/mlxsw/port.h    |   2 -
 drivers/net/ethernet/mellanox/mlxsw/reg.h     | 353 ++++++++++++++++--
 .../ethernet/mellanox/mlxsw/spectrum_fid.c    |   4 +-
 .../mellanox/mlxsw/spectrum_switchdev.c       |   7 +-
 4 files changed, 335 insertions(+), 31 deletions(-)

-- 
2.36.1