netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Machata <petrm@nvidia.com>
To: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	<netdev@vger.kernel.org>
Cc: Ido Schimmel <idosch@nvidia.com>, Petr Machata <petrm@nvidia.com>,
	"Amit Cohen" <amcohen@nvidia.com>, <mlxsw@nvidia.com>
Subject: [PATCH net-next 00/14] mlxsw: Preparations for support of CFF flood mode
Date: Mon, 20 Nov 2023 19:25:17 +0100	[thread overview]
Message-ID: <cover.1700503643.git.petrm@nvidia.com> (raw)

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 is the first in series of two to add CFF flood mode support
to mlxsw.


There are FW versions out there that do not support CFF flood mode, and on
Spectrum-1 in particular, there is no plan to support it at all. mlxsw will
therefore have to support both controlled flood mode as well as CFF.

Another aspect is that at least on Spectrum-1, there are FW versions out
there that claim to support CFF flood mode, but then reject or ignore
configurations enabling the same. The driver thus has to have a say in
whether an attempt to configure CFF flood mode should even be made.

Much like with the LAG mode, the feature is therefore expressed in terms of
"does the driver prefer CFF flood mode?", and "what flood mode the PCI
module managed to configure the FW with". This gives to the driver a chance
to determine whether CFF flood mode configuration should be attempted.


In this patchset, we lay the ground with new definitions, registers and
their fields, and some minor code shaping. The next patchset will be more
focused on introducing necessary abstractions and implementation.

- Patches #1 and #2 add CFF-related items to the command interface.

- Patch #3 adds a new resource, for maximum number of flood profiles
  supported. (A flood profile is a mapping between traffic type and offset
  in the per-FID flood vector table.)

- Patches #4 to #8 adjust reg.h. The SFFP register is added, which is used
  for configuring the abovementioned traffic-type-to-offset mapping. The
  SFMR, register, which serves for FID configuration, is extended with
  fields specific to CFF mode. And other minor adjustments.

- Patches #9 and #10 add the plumbing for CFF mode: a way to request that
  CFF flood mode be configured, and a way to query the flood mode that was
  actually configured.

- Patch #11 removes dead code.

- Patches #12 and #13 add helpers that the next patchset will make use of.
  Patch #14 moves RIF setup ahead so that FID code can make use of it.

Petr Machata (14):
  mlxsw: cmd: Add cmd_mbox.query_fw.cff_support
  mlxsw: cmd: Add MLXSW_CMD_MBOX_CONFIG_PROFILE_FLOOD_MODE_CFF
  mlxsw: resources: Add max_cap_nve_flood_prf
  mlxsw: reg: Add Switch FID Flooding Profiles Register
  mlxsw: reg: Mark SFGC & some SFMR fields as reserved in CFF mode
  mlxsw: reg: Drop unnecessary writes from mlxsw_reg_sfmr_pack()
  mlxsw: reg: Extract flood-mode specific part of mlxsw_reg_sfmr_pack()
  mlxsw: reg: Add to SFMR register the fields related to CFF flood mode
  mlxsw: core, pci: Add plumbing related to CFF mode
  mlxsw: pci: Permit enabling CFF mode
  mlxsw: spectrum_fid: Drop unnecessary conditions
  mlxsw: spectrum_fid: Extract SFMR packing into a helper
  mlxsw: spectrum_router: Add a helper to get subport number from a RIF
  mlxsw: spectrum_router: Call RIF setup before obtaining FID

 drivers/net/ethernet/mellanox/mlxsw/cmd.h     | 11 +++
 drivers/net/ethernet/mellanox/mlxsw/core.c    |  7 ++
 drivers/net/ethernet/mellanox/mlxsw/core.h    |  9 +++
 drivers/net/ethernet/mellanox/mlxsw/pci.c     | 27 ++++++-
 drivers/net/ethernet/mellanox/mlxsw/reg.h     | 78 +++++++++++++++++--
 .../net/ethernet/mellanox/mlxsw/resources.h   |  2 +
 .../net/ethernet/mellanox/mlxsw/spectrum.h    |  2 +
 .../ethernet/mellanox/mlxsw/spectrum_fid.c    | 46 ++++++-----
 .../ethernet/mellanox/mlxsw/spectrum_router.c | 20 ++++-
 9 files changed, 170 insertions(+), 32 deletions(-)

-- 
2.41.0


             reply	other threads:[~2023-11-20 18:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-20 18:25 Petr Machata [this message]
2023-11-20 18:25 ` [PATCH net-next 01/14] mlxsw: cmd: Add cmd_mbox.query_fw.cff_support Petr Machata
2023-11-20 18:25 ` [PATCH net-next 02/14] mlxsw: cmd: Add MLXSW_CMD_MBOX_CONFIG_PROFILE_FLOOD_MODE_CFF Petr Machata
2023-11-20 18:25 ` [PATCH net-next 03/14] mlxsw: resources: Add max_cap_nve_flood_prf Petr Machata
2023-11-20 18:25 ` [PATCH net-next 04/14] mlxsw: reg: Add Switch FID Flooding Profiles Register Petr Machata
2023-11-20 18:25 ` [PATCH net-next 05/14] mlxsw: reg: Mark SFGC & some SFMR fields as reserved in CFF mode Petr Machata
2023-11-20 18:25 ` [PATCH net-next 06/14] mlxsw: reg: Drop unnecessary writes from mlxsw_reg_sfmr_pack() Petr Machata
2023-11-20 18:25 ` [PATCH net-next 07/14] mlxsw: reg: Extract flood-mode specific part of mlxsw_reg_sfmr_pack() Petr Machata
2023-11-20 18:25 ` [PATCH net-next 08/14] mlxsw: reg: Add to SFMR register the fields related to CFF flood mode Petr Machata
2023-11-20 18:25 ` [PATCH net-next 09/14] mlxsw: core, pci: Add plumbing related to CFF mode Petr Machata
2023-11-20 18:25 ` [PATCH net-next 10/14] mlxsw: pci: Permit enabling " Petr Machata
2023-11-20 18:25 ` [PATCH net-next 11/14] mlxsw: spectrum_fid: Drop unnecessary conditions Petr Machata
2023-11-20 18:25 ` [PATCH net-next 12/14] mlxsw: spectrum_fid: Extract SFMR packing into a helper Petr Machata
2023-11-20 18:25 ` [PATCH net-next 13/14] mlxsw: spectrum_router: Add a helper to get subport number from a RIF Petr Machata
2023-11-20 18:25 ` [PATCH net-next 14/14] mlxsw: spectrum_router: Call RIF setup before obtaining FID Petr Machata
2023-11-21 23:00 ` [PATCH net-next 00/14] mlxsw: Preparations for support of CFF flood mode patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1700503643.git.petrm@nvidia.com \
    --to=petrm@nvidia.com \
    --cc=amcohen@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).