[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1701183891.git.petrm@nvidia.com>
Date: Tue, 28 Nov 2023 16:50:33 +0100
From: Petr Machata <petrm@...dia.com>
To: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, <netdev@...r.kernel.org>
CC: Ido Schimmel <idosch@...dia.com>, Petr Machata <petrm@...dia.com>, "Amit
Cohen" <amcohen@...dia.com>, <mlxsw@...dia.com>
Subject: [PATCH net-next 00/17] mlxsw: Support CFF flood mode
The registers to configure to initialize a flood table differ between the
controlled and CFF flood modes. In therefore needs to be an op. Add it,
hook up the current init to the existing families, and invoke the op.
PGT is an in-HW table that maps addresses to sets of ports. Then when some
HW process needs a set of ports as an argument, instead of embedding the
actual set in the dynamic configuration, what gets configured is the
address referencing the set. The HW then works with the appropriate PGT
entry.
Among other allocations, the PGT currently contains two large blocks for
bridge flooding: one for 802.1q and one for 802.1d. Within each of these
blocks are three tables, for unknown-unicast, multicast and broadcast
flooding:
. . . | 802.1q | 802.1d | . . .
| UC | MC | BC | UC | MC | BC |
\______ _____/ \_____ ______/
v v
FID flood vectors
Thus each FID (which corresponds to an 802.1d bridge or one VLAN in an
802.1q bridge) uses three flood vectors spread across a fairly large region
of PGT.
This way of organizing the flood table (called "controlled") is not very
flexible. E.g. to decrease a bridge scale and store more IP MC vectors, one
would need to completely rewrite the bridge PGT blocks, or resort to hacks
such as storing individual MC flood vectors into unused part of the bridge
table.
In order to address these shortcomings, Spectrum-2 and above support what
is called CFF flood mode, for Compressed FID Flooding. In CFF flood mode,
each FID has a little table of its own, with three entries adjacent to each
other, one for unknown-UC, one for MC, one for BC. This allows for a much
more fine-grained approach to PGT management, where bits of it are
allocated on demand.
. . . | FID | FID | FID | FID | FID | . . .
|U|M|B|U|M|B|U|M|B|U|M|B|U|M|B|
\_____________ _____________/
v
FID flood vectors
Besides the FID table organization, the CFF flood mode also impacts Router
Subport (RSP) table. This table contains flood vectors for rFIDs, which are
FIDs that reference front panel ports or LAGs. The RSP table contains two
entries per front panel port and LAG, one for unknown-UC traffic, and one
for everything else. Currently, the FW allocates and manages the table in
its own part of PGT. rFIDs are marked with flood_rsp bit and managed
specially. In CFF mode, rFIDs are managed as all other FIDs. The driver
therefore has to allocate and maintain the flood vectors. Like with bridge
FIDs, this is more work, but increases flexibility of the system.
The FW currently supports both the controlled and CFF flood modes. To shed
complexity, in the future it should only support CFF flood mode. Hence this
patchset, which adds CFF flood mode support to mlxsw.
Since mlxsw needs to maintain both the controlled mode as well as CFF mode
support, we will keep the layout as compatible as possible. The bridge
tables will stay in the same overall shape, just their inner organization
will change from flood mode -> FID to FID -> flood mode. Likewise will RSP
be kept as a contiguous block of PGT memory, as was the case when the FW
maintained it.
- The way FIDs get configured under the CFF flood mode differs from the
currently used controlled mode. The simple approach of having several
globally visible arrays for spectrum.c to statically choose from no
longer works.
Patch #1 thus privatizes all FID initialization and finalization logic,
and exposes it as ops instead.
- Patch #2 renames the ops that are specific to the controlled mode, to
make room in the namespace for the CFF variants.
Patch #3 extracts a helper to compute flood table base out of
mlxsw_sp_fid_flood_table_mid().
- The op fid_setup configured fid_offset, i.e. the number of this FID
within its family. For rFIDs in CFF mode, to determine this number, the
driver will need to do fallible queries.
Thus in patch #4, make the FID setup operation fallible as well.
- Flood mode initialization routine differs between the controlled and CFF
flood modes. The controlled mode needs to configure flood table layout,
which the CFF mode does not need to do.
In patch #5, move mlxsw_sp_fid_flood_table_init() up so that the
following patch can make use of it.
In patch #6, add an op to be invoked per table (if defined).
- The current way of determining PGT allocation size depends on the number
of FIDs and number of flood tables. RFIDs however have PGT footprint
depending not on number of FIDs, but on number of ports and LAGs, because
which ports an rFID should flood to does not depend on the FID itself,
but on the port or LAG that it references.
Therefore in patch #7, add FID family ops for determining PGT allocation
size.
- As elaborated above, layout of PGT will differ between controlled and CFF
flood modes. In CFF mode, it will further differ between rFIDs and other
FIDs (as described at previous patch). The way to pack the SFMR register
to configure a FID will likewise differ from controlled to CFF.
Thus in patches #8 and #9 add FID family ops to determine PGT base
address for a FID and to pack SFMR.
- Patches #10 and #11 add more bits for RSP support. In patch #10, add a
new traffic type enumerator, for non-UC traffic. This is a combination of
BC and MC traffic, but the way that mlxsw maps these mnemonic names to
actual traffic type configurations requires that we have a new name to
describe this class of traffic.
Patch #11 then adds hooks necessary for RSP table maintenance. As ports
come and go, and join and leave LAGs, it is necessary to update flood
vectors that the rFIDs use. These new hooks will make that possible.
- Patches #12, #13 and #14 introduce flood profiles. These have been
implicit so far, but the way that CFF flood mode works with profile IDs
requires that we make them explicit.
Thus in patch #12, introduce flood profile objects as a set of flood
tables that FID families then refer to. The FID code currently only
uses a single flood profile.
In patch #13, add a flood profile ID to flood profile objects.
In patch #14, when in CFF mode, configure SFFP according to the existing
flood profiles (or the one that exists as of that point).
- Patches #15 and #16 add code to implement, respectively, bridge FIDs and
RSP FIDs in CFF mode.
- In patch #17, toggle flood_mode_prefer_cff on Spectrum-2 and above, which
makes the newly-added code live.
Petr Machata (17):
mlxsw: spectrum_fid: Privatize FID families
mlxsw: spectrum_fid: Rename FID ops, families, arrays
mlxsw: spectrum_fid: Split a helper out of
mlxsw_sp_fid_flood_table_mid()
mlxsw: spectrum_fid: Make mlxsw_sp_fid_ops.setup return an int
mlxsw: spectrum_fid: Move mlxsw_sp_fid_flood_table_init() up
mlxsw: spectrum_fid: Add an op for flood table initialization
mlxsw: spectrum_fid: Add an op to get PGT allocation size
mlxsw: spectrum_fid: Add an op to get PGT address of a FID
mlxsw: spectrum_fid: Add an op for packing SFMR
mlxsw: spectrum_fid: Add a not-UC packet type
mlxsw: spectrum_fid: Add hooks for RSP table maintenance
mlxsw: spectrum_fid: Add an object to keep flood profiles
mlxsw: spectrum_fid: Add profile_id to flood profile
mlxsw: spectrum_fid: Initialize flood profiles in CFF mode
mlxsw: spectrum_fid: Add a family for bridge FIDs in CFF flood mode
mlxsw: spectrum_fid: Add support for rFID family in CFF flood mode
mlxsw: spectrum: Use CFF mode where available
.../net/ethernet/mellanox/mlxsw/spectrum.c | 28 +-
.../net/ethernet/mellanox/mlxsw/spectrum.h | 17 +-
.../ethernet/mellanox/mlxsw/spectrum_fid.c | 792 +++++++++++++++---
3 files changed, 727 insertions(+), 110 deletions(-)
--
2.41.0
Powered by blists - more mailing lists