1. 22 Jun, 2022 7 commits
  2. 21 Jun, 2022 15 commits
  3. 20 Jun, 2022 18 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
    • Amit Cohen's avatar
      mlxsw: reg: Add Router Egress Interface to VID Register · 27f0b6ce
      Amit Cohen authored
      The REIV maps {egress router interface (eRIF), egress_port} -> {vlan ID}.
      As preparation for unified bridge model, add REIV register for future use.
      
      In the past, firmware would take care of the above mentioned mapping,
      but in the new model this should be done by software using REIV register.
      
      REIV register supports a simultaneous update of 256 ports using
      'port_page' field. When 'port_page'=0 the records represent ports
      0-255, when 'port_page'=1 the records represent ports 256-511 and so
      on.
      
      The register is reserved while using the legacy model.
      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>
      27f0b6ce
    • Amit Cohen's avatar
      mlxsw: reg: Replace MID related fields in SFGC register · 48bca94f
      Amit Cohen authored
      SFGC register maps {packet type, bridge type} -> {MID base, table type}.
      As preparation for unified bridge model, remove 'mid' field and add
      'mid_base' field.
      
      The MID index (index to PGT table which maps MID to local port list and
      SMPE index) is a result of 'mid_base' + 'fid_offset'. Using the legacy
      bridge model, firmware configures 'mid_base'. However, using the new model,
      software is responsible to configure it via SFGC register.
      
      The 'mid_base' is configured per {packet type, bridge type}, for
      example, for {Unicast, .1Q}, {Broadcast, .1D}.
      
      Add the field 'mid_base' to SFGC register and increase the length of the
      register accordingly.
      
      Remove the field 'mid' as currently it is ignored by the device, its use
      is an old leftover.
      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>
      48bca94f
    • Amit Cohen's avatar
      mlxsw: reg: Add flood related field to SFMR register · 94536249
      Amit Cohen authored
      SFMR register creates and configures FIDs. As preparation for unified
      bridge model, add a required field for future use.
      
      The PGT (Port Group) table maps multicast ID (MID) to
      {local port list, SMPE index} on Spectrum-1 and to {local port list} on
      the other ASICs.
      
      In the legacy model, software did not interact with this table directly.
      Instead, it was accessed by firmware in response to registers such as
      SFTR and SMID.
      In the new model, the SFTR register is deprecated and software has full
      control over the PGT table using the SMID register.
      
      The configuration of MDB entries (using SFD) is unchanged, but flooding
      configuration is completely different.
      SFGC register maps {packet type, bridge type} -> {MID base, table type},
      then with FID and FID-offset which are configured via SFMR, the MID index
      is obtained.
      
      Add the field 'flood_bridge_type' to SFMR, software can separate between
      802.1q FIDs and vFIDs using two types which are supported.
      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>
      94536249
    • Amit Cohen's avatar
      mlxsw: reg: Add VID related fields to SFD register · 485c281c
      Amit Cohen authored
      SFD register configures FDB table. As preparation for unified bridge model,
      add some required fields for future use.
      
      In the new model, firmware no longer configures the egress VID, this
      responsibility is moved to software. For layer 2 this means that software
      needs to determine the egress VID for both unicast and multicast.
      
      For unicast FDB records and unicast LAG FDB records, the VID needs to be
      set via new fields in SFD - 'set_vid' and 'vid'.
      
      Add the two mentioned fields for future use.
      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>
      485c281c
    • Amit Cohen's avatar
      mlxsw: reg: Add SMPE related fields to SFMR register · 92e4e543
      Amit Cohen authored
      SFMR register creates and configures FIDs. As preparation unified bridge
      model, add some required fields for future use.
      
      The device includes two main tables to support layer 2 multicast (i.e.,
      MDB and flooding). These are the PGT (Port Group Table) and the
      MPE (Multicast Port Egress) table.
      - PGT is {MID -> (bitmap of local_port, SPME index)}
      - MPE is {(Local port, SMPE index) -> eVID}
      
      In Spectrum-2 and later ASICs, the SMPE index is an attribute of the FID
      and programmed via new fields in SFMR register - 'smpe_valid' and 'smpe'.
      
      Add the two mentioned fields for future use and increase the length of
      the register accordingly.
      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>
      92e4e543
    • Amit Cohen's avatar
      mlxsw: Add SMPE related fields to SMID2 register · 894b98d5
      Amit Cohen authored
      SMID register maps multicast ID (MID) into a list of local ports.
      As preparation for unified bridge model, add some required fields for
      future use.
      
      The device includes two main tables to support layer 2 multicast (i.e.,
      MDB and flooding). These are the PGT (Port Group Table) and the
      MPE (Multicast Port Egress) table.
      - PGT is {MID -> (bitmap of local_port, SPME index)}
      - MPE is {(Local port, SMPE index) -> eVID}
      
      In Spectrum-1, both indexes into the MPE table (local port and SMPE) are
      derived from the PGT table. Therefore, the SMPE index needs to be
      programmed as part of the PGT entry via new fields in SMID - 'smpe_valid'
      and 'smpe'.
      
      Add the two mentioned fields for future use and align the callers of
      mlxsw_reg_smid2_pack() to pass zeros for SMPE fields.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      894b98d5
    • Amit Cohen's avatar
      mlxsw: reg: Add Switch Multicast Port to Egress VID Register · e0f071c5
      Amit Cohen authored
      The SMPE register maps {egress_port, SMPE index} -> VID.
      
      The device includes two main tables to support layer 2 multicast (i.e.,
      MDB and flooding). These are the PGT (Port Group Table) and the
      MPE (Multicast Port Egress) table.
      - PGT is {MID -> (bitmap of local_port, SPME index)}
      - MPE is {(Local port, SMPE index) -> eVID}
      
      In Spectrum-1, the index into the MPE table - called switch multicast to
      port egress VID (SMPE) - is derived from the PGT entry, whereas in
      Spectrum-2 and later ASICs it is derived from the FID.
      
      In the legacy model, software did not interact with this table as it was
      completely hidden in firmware. In the new model, software needs to
      populate the table itself in order to map from {Local port, SMPE index} to
      an egress VID. This is done using the SMPE register.
      
      Add the register for future use.
      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>
      e0f071c5
    • Amit Cohen's avatar
      mlxsw: reg: Add ingress RIF related fields to SVFA register · dd326565
      Amit Cohen authored
      SVFA register controls the VID to FID mapping and {Port, VID} to FID
      mapping for virtualized ports. As preparation for unified bridge model,
      add some required fields for future use.
      
      On ingress, after ingress ACL, a packet needs to be classified to a FID.
      The key for this lookup can be one of:
      1. VID. When port is not in virtual mode.
      2. {RQ, VID}. When port is in virtual mode.
      3. FID. When FID was set by ingress ACL.
      
      Since RITR no longer performs ingress configuration, the ingress RIF for
      the first two entry types needs to be set via new fields in SVFA -
      'irif_v' and 'irif'.
      
      Add the two mentioned fields for future use and increase the length of
      the register accordingly.
      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>
      dd326565
    • Amit Cohen's avatar
      mlxsw: reg: Add ingress RIF related fields to SFMR register · e459466a
      Amit Cohen authored
      SFMR register creates and configures FIDs. As preparation for unified
      bridge model, add some required fields for future use.
      
      On ingress, after ingress ACL, a packet needs to be classified to a FID.
      The key for this lookup can be one of:
      1. VID. When port is not in virtual mode.
      2. {RQ, VID}. When port is in virtual mode.
      3. FID. When FID was set by ingress ACL.
         For example, via VR_AND_FID_ACTION.
      
      Since RITR no longer performs ingress configuration, the ingress RIF for
      the last entry type needs to be set via new fields in SFMR - 'irif_v'
      and 'irif'.
      
      Add the two mentioned fields for future use.
      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>
      e459466a
    • Amit Cohen's avatar
      mlxsw: reg: Add 'flood_rsp' field to SFMR register · 02d23c95
      Amit Cohen authored
      SFMR register creates and configures FIDs. As preparation for unified
      bridge model, add a field for future use.
      
      In the new model, RITR no longer configures the rFID used for sub-port RIFs
      and it has to be created by software via SFMR. Such FIDs need to be created
      with special flood indication using 'flood_rsp' field. When set, this bit
      instructs the device to manage the flooding entries for this FID in a
      reserved part of the port group table (PGT).
      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>
      02d23c95
    • Ronak Doshi's avatar
      vmxnet3: disable overlay offloads if UPT device does not support · a56b158a
      Ronak Doshi authored
      'Commit 6f91f4ba ("vmxnet3: add support for capability registers")'
      added support for capability registers. These registers are used
      to advertize capabilities of the device.
      
      The patch updated the dev_caps to disable outer checksum offload if
      PTCR register does not support it. However, it missed to update
      other overlay offloads. This patch fixes this issue.
      
      Fixes: 6f91f4ba ("vmxnet3: add support for capability registers")
      Signed-off-by: default avatarRonak Doshi <doshir@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a56b158a
    • David S. Miller's avatar
      Merge branch 'raw-rcu-fixes' · 6f9d7046
      David S. Miller authored
      Kuniyuki Iwashima says:
      
      ====================
      raw: Fix nits of RCU conversion series.
      
      The first patch fixes a build error by commit ba44f818 ("raw: use
      more conventional iterators"), but it does not land in the net tree,
      so this series is targeted to net-next.  The second patch replaces some
      hlist functions with sk's helper macros.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f9d7046
    • Kuniyuki Iwashima's avatar
      raw: Use helpers for the hlist_nulls variant. · f289c02b
      Kuniyuki Iwashima authored
      hlist_nulls_add_head_rcu() and hlist_nulls_for_each_entry() have dedicated
      macros for sk.
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f289c02b
    • Kuniyuki Iwashima's avatar
      raw: Fix mixed declarations error in raw_icmp_error(). · 5da39e31
      Kuniyuki Iwashima authored
      The trailing semicolon causes a compiler error, so let's remove it.
      
      net/ipv4/raw.c: In function ‘raw_icmp_error’:
      net/ipv4/raw.c:266:2: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
        266 |  struct hlist_nulls_head *hlist;
            |  ^~~~~~
      
      Fixes: ba44f818 ("raw: use more conventional iterators")
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5da39e31