Skip to content

L
linux
Switch branch/tag
  1. 29 Jun, 2022 24 commits
  3. 28 Jun, 2022 16 commits
    • Paolo Abeni's avatar
      Merge branch 'mlxsw-unified-bridge-conversion-part-4-6' · d521bc0a
      Paolo Abeni authored 
      Ido Schimmel says:

====================
mlxsw: Unified bridge conversion - part 4/6

This is the fourth part of the conversion of mlxsw to the unified bridge
model.

Unlike previous parts that prepared mlxsw for the conversion, this part
actually starts the conversion. It focuses on flooding configuration and
converts mlxsw to the more "raw" APIs of the unified bridge model.

The patches configure the different stages of the flooding pipeline in
Spectrum that looks as follows (at a high-level):

         +------------+                +----------+           +-------+
  {FID,  |            | {Packet type,  |          |           |       |  MID
   DMAC} | FDB lookup |  Bridge type}  |   SFGC   | MID base  |       | Index
+-------->   (miss)   +----------------> register +-----------> Adder +------->
         |            |                |          |           |       |
         |            |                |          |           |       |
         +------------+                +----+-----+           +---^---+
                                            |                     |
                                    Table   |                     |
                                     type   |                     | Offset
                                            |      +-------+      |
                                            |      |       |      |
                                            |      |       |      |
                                            +----->+  Mux  +------+
                                                   |       |
                                                   |       |
                                                   +-^---^-+
                                                     |   |
                                                  FID|   |FID
                                                     |   |offset
                                                     +   +

The multicast identifier (MID) index is used as an index to the port
group table (PGT) that contains a bitmap of ports via which a packet
needs to be replicated.

From the PGT table, the packet continues to the multicast port egress
(MPE) table that determines the packet's egress VLAN. This is a
two-dimensional table that is indexed by port and switch multicast port
to egress (SMPE) index. The latter can be thought of as a FID. Without
it, all the packets replicated via a certain port would get the same
VLAN, regardless of the bridge domain (FID).

Logically, these two steps look as follows:

                     PGT table                           MPE table
             +-----------------------+               +---------------+
             |                       | {Local port,  |               | Egress
  MID index  | Local ports bitmap #1 |  SMPE index}  |               |  VID
+------------>        ...            +--------------->               +-------->
             | Local ports bitmap #N |               |               |
             |                       |          SMPE |               |
             +-----------------------+               +---------------+
                                                        Local port

Patchset overview:

Patch #1 adds a variable to guard against mixed model configuration.
Will be removed in part 6 when mlxsw is fully converted to the unified
model.

Patches #2-#5 introduce two new FID attributes required for flooding
configuration in the new model:

1. 'flood_rsp': Instructs the firmware to handle flooding configuration
for this FID. Only set for router FIDs (rFIDs) which are used to connect
a {Port, VLAN} to the router block.

2. 'bridge_type': Allows the device to determine the flood table (i.e.,
base index to the PGT table) for the FID. The first type will be used
for FIDs in a VLAN-aware bridge and the second for FIDs representing
VLAN-unaware bridges.

Patch #6 configures the MPE table that determines the egress VLAN of a
packet that is forwarded according to L2 multicast / flood.

Patches #7-#11 add the PGT table and related APIs to allocate entries
and set / clear ports in them.

Patches #12-#13 convert the flooding configuration to use the new PGT
APIs.
====================

Link: https://lore.kernel.org/r/20220627070621.648499-1-idosch@nvidia.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      d521bc0a
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Configure flooding entries using PGT APIs · fe94df6d
      Amit Cohen authored 
      The PGT (Port Group Table) table maps an index to a bitmap of local ports
to which a packet needs to be replicated. This table is used for layer 2
multicast and flooding.

In the legacy model, software did not interact with PGT 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.

Use the new PGT APIs to allocate entries for flooding as part of flood
tables initialization. Add mlxsw_sp_fid_flood_tables_fini() to free the
allocated indexes. In addition, use PGT APIs to add/remove ports from PGT
table. The existing code which configures the flood entries via SFTR2 will
be removed later.
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 avatarPaolo Abeni <pabeni@redhat.com>
      fe94df6d
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Set 'mid_base' as part of flood tables initialization · 9f6f467a
      Amit Cohen authored 
      The PGT (Port Group Table) table maps an index to a bitmap of local ports
to which a packet needs to be replicated. This table is used for layer 2
multicast and flooding.

The index to PGT table which is called 'mid_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 first 15K entries will
be used for flooding and the rest for multicast. The table will look as
follows:

+----------------------------+
|                            |
| 802.1q, unicast flooding   | 4K entries
|                            |
+----------------------------+
|                            |
| 802.1q, multicast flooding | 4K entries
|                            |
+----------------------------+
|                            |
| 802.1q, broadcast flooding | 4K entries
|                            |
+----------------------------+
| 802.1d, unicast flooding   | 1K entries
+----------------------------+
| 802.1d, multicast flooding | 1K entries
+----------------------------+
| 802.1d, broadcast flooding | 1K entries
+----------------------------+
|                            |
|                            |
|    Multicast entries       | The rest of the table
|                            |
|                            |
+----------------------------+

Add 'pgt_base' to 'struct mlxsw_sp_fid_family' and use it to calculate
MID base, set 'SFGC.mid_base' as part of flood tables initialization.
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 avatarPaolo Abeni <pabeni@redhat.com>
      9f6f467a
    • Amit Cohen's avatar
      mlxsw: spectrum: Initialize PGT table · bb1bba35
      Amit Cohen authored 
      Initialize PGT table as part of mlxsw_sp_init(). This table will be used
first in the next patch by FID code to set flooding entries, and later by
MDB code to add multicast entries.
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 avatarPaolo Abeni <pabeni@redhat.com>
      bb1bba35
    • Amit Cohen's avatar
      mlxsw: Extend PGT APIs to support maintaining list of ports per entry · a3a7992b
      Amit Cohen authored 
      Add an API to associate a PGT entry with SMPE index and add or remove a
port. This API will be used by FID code and MDB code, to add/remove port
from specific PGT entry.

When the first port is added to PGT entry, allocate the entry in the given
MID index, when the last port is removed from PGT entry, free it.
Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      a3a7992b
    • Amit Cohen's avatar
      mlxsw: Add a dedicated structure for bitmap of ports · d7a7b697
      Amit Cohen authored 
      Currently when bitmap of ports is needed, 'unsigned long *' type is
used. The functions which use the bitmap assume its length according to
its name, i.e., each function which gets a bitmap of ports queries the
maximum number of ports and uses it as the size.

As preparation for the next patch which will use bitmap of ports, add a
dedicated structure for it. Refactor the existing code to use the new
structure.
Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      d7a7b697
    • Amit Cohen's avatar
      mlxsw: Add an indication of SMPE index validity for PGT table · a1697d11
      Amit Cohen authored 
      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.

Therefore, in Spectrum-1, the SMPE index needs to be programmed as part of
the PGT entry via SMID register, while it is reserved for Spectrum-2 and
later ASICs.

Add 'pgt_smpe_index_valid' boolean as part of 'struct mlxsw_sp' and set
it to true for Spectrum-1 and to false for the later ASICs. Add
'smpe_index_valid' as part of 'struct mlxsw_sp_pgt' and set it according
to the value in 'struct mlxsw_sp' as part of PGT initialization.
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 avatarPaolo Abeni <pabeni@redhat.com>
      a1697d11
    • Amit Cohen's avatar
      mlxsw: Add an initial PGT table support · d8782ec5
      Amit Cohen authored 
      The PGT (Port Group Table) table maps an index to a bitmap of local ports
to which a packet needs to be replicated. This table is used for layer 2
multicast and flooding.

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 entire state of the PGT table needs to be maintained in software
because member ports in a PGT entry needs to be reference counted to avoid
releasing entries which are still in use.

Add the following APIs:
1. mlxsw_sp_pgt_{init, fini}() - allocate/free the PGT table.
2. mlxsw_sp_pgt_mid_alloc_range() - allocate a range of MID indexes in PGT.
   To be used by FID code during initialization to reserve specific PGT
   indexes for flooding entries.
3. mlxsw_sp_pgt_mid_free_range() - free indexes in a given range.
4. mlxsw_sp_pgt_mid_alloc() - allocate one MID index in the PGT at a
   non-specific range, just search for free index. To be used by MDB code.
5. mlxsw_sp_pgt_mid_free() - free the given index.

Note that alloc() functions do not allocate the entries in software, just
allocate IDs using 'idr'.
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 avatarPaolo Abeni <pabeni@redhat.com>
      d8782ec5
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Configure egress VID classification for multicast · 8c2da081
      Amit Cohen authored 
      The device includes two main tables to support layer 2 multicast (i.e.,
MDB and flooding). These are the PGT (Port Group Table) 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 the legacy model, software did not interact with MPE 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} to an
egress VID. This is done using the SMPE register.

Configure SMPE register when a {Local port, VID} are mapped/unmapped to a
802.1d and 802.1q emulated FIDs. The MPE table is not relevant for rFIDs as
firmware handles their flooding.
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 avatarPaolo Abeni <pabeni@redhat.com>
      8c2da081
    • Amit Cohen's avatar
      mlxsw: Set flood bridge type for FIDs · aa845e36
      Amit Cohen authored 
      In the unified bridge model, the bridge type FID attribute is no longer
configured by the firmware, but instead by software when creating and
editing a FID via SFMR register.

Set this field as part of FID creation and edition flow. Default to 0
(reserved) as long as the driver operates in the legacy bridge 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 avatarPaolo Abeni <pabeni@redhat.com>
      aa845e36
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Store 'bridge_type' as part of FID family · dd8c77d5
      Amit Cohen authored 
      Currently, 'bridge_type' is an attribute of 'struct mlxsw_sp_flood_table',
which is defined per FID family. Instead, it can be an attribute of
'struct mlxsw_sp_fid_family' as all flood tables in the same family are of
the same type. This change will ease the configuration of
'SFMR.flood_bridge_type' which will be added in the next patch.
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 avatarPaolo Abeni <pabeni@redhat.com>
      dd8c77d5
    • Amit Cohen's avatar
      mlxsw: Prepare 'bridge_type' field for SFMR usage · fad8e1b6
      Amit Cohen authored 
      Under the legacy bridge model, the field 'bridge_type' is used only
in SFGC register, to determine the type of flood table (FID/FID offset).

Under the unified bridge model, it will be used also in SFMR register.
When a BUM packet needs to be flooded, SFGC is used to provide the
'mid_base' for PGT table. The access to SFGC is by
{packet type, bridge type}. Under the unified bridge model, software is
responsible for configuring 'bridge_type' as part of SFMR.

As preparation for the new required configuration, rename
'enum mlxsw_reg_sfgc_bridge_type' to 'enum mlxsw_reg_bridge_type'. Then
it can be used also in SFMR. In addition, align the names of the values to
internal documentation.
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 avatarPaolo Abeni <pabeni@redhat.com>
      fad8e1b6
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Configure flooding table type for rFID · 93303ff8
      Amit Cohen authored 
      Using unified bridge model, RITR register no longer configures the rFID
used for sub-port RIFs. It needs to be created by software via SFMR. Such
FIDs need to be created with a special flood indication using
'SFMR.flood_rsp=1'. It means that for such FIDs, router sub-port flooding
table will be used, this table is configured by firmware.

Set the above mentioned field as part of FID initialization and FID
edition, so then when other fields will be updated in SFMR, this field
will store the correct value and will not be overwritten.

Add 'flood_rsp' variable to 'struct mlxsw_sp_fid_family', set it to true
for rFID and to false for the rest.
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 avatarPaolo Abeni <pabeni@redhat.com>
      93303ff8
    • Amit Cohen's avatar
      mlxsw: spectrum: Add a temporary variable to indicate bridge model · d6d90266
      Amit Cohen authored 
      As part of transition to unified bridge model, many different firmware
configurations are done.

Some of the configuration that needs to be done for the unified bridge
model is not valid under the legacy model, and would be rejected by the
firmware. At the same time, the driver cannot switch to the unified bridge
model until all of the code has been converted.

To allow breaking the change into patches, and to not break driver
behavior during the transition, add a boolean variable to indicate bridge
model. Then, forbidden configurations will be skipped using the check -
"if (!mlxsw_sp->ubridge)".

The new variable is temporary for several sets, it will be removed when
firmware will be configured to work with unified bridge 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 avatarPaolo Abeni <pabeni@redhat.com>
      d6d90266
    • Sam Edwards's avatar
      ipv6/addrconf: fix timing bug in tempaddr regen · 778964f2
      Sam Edwards authored 
      The addrconf_verify_rtnl() function uses a big if/elseif/elseif/... block
to categorize each address by what type of attention it needs.  An
about-to-expire (RFC 4941) temporary address is one such category, but the
previous elseif branch catches addresses that have already run out their
prefered_lft.  This means that if addrconf_verify_rtnl() fails to run in
the necessary time window (i.e. REGEN_ADVANCE time units before the end of
the prefered_lft), the temporary address will never be regenerated, and no
temporary addresses will be available until each one's valid_lft runs out
and manage_tempaddrs() begins anew.

Fix this by moving the entire temporary address regeneration case out of
that block.  That block is supposed to implement the "destructive" part of
an address's lifecycle, and regenerating a fresh temporary address is not,
semantically speaking, actually tied to any particular lifecycle stage.
The age test is also changed from `age >= prefered_lft - regen_advance`
to `age + regen_advance >= prefered_lft` instead, to ensure no underflow
occurs if the system administrator increases the regen_advance to a value
greater than the already-set prefered_lft.

Note that this does not fix the problem of addrconf_verify_rtnl() sometimes
not running in time, resulting in the race condition described in RFC 4941
section 3.4 - it only ensures that the address is regenerated.  Fixing THAT
problem may require either using jiffies instead of seconds for all time
arithmetic here, or always rounding up when regen_advance is converted to
seconds.
Signed-off-by: default avatarSam Edwards <CFSworks@gmail.com>
Link: https://lore.kernel.org/r/20220623181103.7033-1-CFSworks@gmail.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      778964f2
    • Christophe JAILLET's avatar
      hinic: Use the bitmap API when applicable · 7c2c5726
      Christophe JAILLET authored 
      'vlan_bitmap' is a bitmap and is used as such. So allocate it with
devm_bitmap_zalloc() and its explicit bit size (i.e. VLAN_N_VID).

This avoids the need of the VLAN_BITMAP_SIZE macro which:
   - needlessly has a 'nic_dev' parameter
   - should be "long" (and not byte) aligned, so that the bitmap semantic
     is respected

This is in fact not an issue because VLAN_N_VID is 4096 at the time
being, but devm_bitmap_zalloc() is less verbose and easier to understand.
Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/6ff7b7d21414240794a77dc2456914412718a145.1656260842.git.christophe.jaillet@wanadoo.frSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7c2c5726
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7