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 v2 0/3] mlxsw: Improve blocks selection for IPv6 multicast forwarding
Date: Tue, 19 Sep 2023 17:42:53 +0200 [thread overview]
Message-ID: <cover.1695137616.git.petrm@nvidia.com> (raw)
Amit Cohen writes:
The driver configures two ACL regions during initialization, these regions
are used for IPv4 and IPv6 multicast forwarding. Entries residing in these
two regions match on the {SIP, DIP, VRID} key elements.
Currently for IPv6 region, 9 key blocks are used. This can be improved by
reducing the amount key blocks needed for the IPv6 region to 8. It is
possible to use key blocks that mix subsets of the VRID element with
subsets of the DIP element.
To make this happen, we have to take in account the algorithm that chooses
which key blocks will be used. It is lazy and not the optimal one as it is
a complex task. It searches the block that contains the most elements that
are required, chooses it, removes the elements that appear in the chosen
block and starts again searching the block that contains the most elements.
To optimize the nubmber of the blocks for IPv6 multicast forwarding, handle
the following:
1. Add support for key blocks that mix subsets of the VRID element with
subsets of the DIP element.
2. Prevent the algorithm from chosing another blocks for VRID.
Currently, we have the block 'ipv4_4' which contains 2 sub-elements of
VRID. With the existing algorithm, this block might be chosen, then 8
blocks must be chosen for SIP and DIP and we will get 9 blocks to match on
{SIP, DIP, VRID}. Therefore, replace this block with a new block 'ipv4_5'
that contains 1 element for VRID, this will not be chosen for IPv6 as VRID
element will be broken to several sub-elements. In this way we can get 8
blocks for IPv6 multicast forwarding.
This improvement was tested and indeed 8 blocks are used instead of 9.
v2:
- Resending without changes.
Amit Cohen (3):
mlxsw: Add 'ipv4_5' flex key
mlxsw: spectrum_acl_flex_keys: Add 'ipv4_5b' flex key
mlxsw: Edit IPv6 key blocks to use one less block for multicast
forwarding
.../mellanox/mlxsw/core_acl_flex_keys.c | 6 ++++--
.../mellanox/mlxsw/core_acl_flex_keys.h | 6 ++++--
.../mellanox/mlxsw/spectrum2_mr_tcam.c | 20 +++++++++++--------
.../mellanox/mlxsw/spectrum_acl_flex_keys.c | 18 +++++++++--------
4 files changed, 30 insertions(+), 20 deletions(-)
--
2.41.0
next reply other threads:[~2023-09-19 15:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 15:42 Petr Machata [this message]
2023-09-19 15:42 ` [PATCH net-next v2 1/3] mlxsw: Add 'ipv4_5' flex key Petr Machata
2023-09-19 15:42 ` [PATCH net-next v2 2/3] mlxsw: spectrum_acl_flex_keys: Add 'ipv4_5b' " Petr Machata
2023-09-19 15:42 ` [PATCH net-next v2 3/3] mlxsw: Edit IPv6 key blocks to use one less block for multicast forwarding Petr Machata
2023-09-22 7:30 ` [PATCH net-next v2 0/3] mlxsw: Improve blocks selection for IPv6 " 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.1695137616.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).