1. 22 Jun, 2022 21 commits
  2. 21 Jun, 2022 15 commits
  3. 20 Jun, 2022 4 commits
    • David S. Miller's avatar
      Merge branch 'mlxsw-unified-bridge-conversion-part-1' · 4336487e
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      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 50853808 ("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.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4336487e
    • Amit Cohen's avatar
      mlxsw: reg: Add support for VLAN RIF as part of RITR register · b3820922
      Amit Cohen authored
      Router interfaces (RIFs) constructed on top of VLAN-aware bridges are of
      "VLAN" type, whereas RIFs constructed on top of VLAN-unaware bridges of
      "FID" type.
      
      In other words, the RIF type is derived from the underlying FID type.
      VLAN RIFs are used on top of 802.1Q FIDs, whereas FID RIFs are used on
      top of 802.1D FIDs.
      
      Currently 802.1Q FIDs are emulated using 802.1D FIDs, and therefore VLAN
      RIFs are emulated using FID RIFs.
      
      As part of converting the driver to use unified bridge, 802.1Q FIDs and
      VLAN RIFs will be used.
      
      Add the relevant fields to RITR register, add pack() function for VLAN
      RIF and rename one field to fit the internal name.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3820922
    • Amit Cohen's avatar
      mlxsw: Add support for egress FID classification after decapsulation · 1b1c198c
      Amit Cohen authored
      As preparation for unified bridge model, add support for VNI->FID mapping
      via SVFA register.
      
      When performing VXLAN encapsulation, the VXLAN header needs to contain a
      VNI. This VNI is derived from the FID classification performed on
      ingress, through which the ingress RIF is also determined.
      
      Similarly, when performing VXLAN decapsulation, the FID of the packet
      needs to be determined. This FID is derived from VNI classification
      performed during decapsulation.
      
      In the old model, both entries (i.e., FID->VNI and VNI->FID) were
      configured via SFMR.vni.
      
      In the new model, where ingress is separated from egress, ingress
      configuration (VNI->FID) is performed via SVFA, while SFMR only
      configures egress (FID->VNI).
      
      Add 'vni' field to SVFA, add new mapping table - VNI to FID, add new
      pack() function for VNI mapping and edit the comment in SFMR.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b1c198c
    • Amit Cohen's avatar
      mlxsw: reg: Add egress FID field to RITR register · ad9592c0
      Amit Cohen authored
      RITR configures the router interface table. As preparation for unified
      bridge model, add egress FID field to RITR.
      
      After routing, a packet has to perform a layer-2 lookup using the
      destination MAC it got from the routing and a FID.
      In the new model, the egress FID is configured by RITR for both sub-port
      and FID RIFs.
      
      Add 'efid' field to sub-port router interface and update FID router
      interface related comment.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad9592c0