All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: "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, Ido Schimmel <idosch@nvidia.com>,
	Amit Cohen <amcohen@nvidia.com>,
	mlxsw@nvidia.com
Subject: Re: [PATCH net-next 0/5] mlxsw: Control the order of blocks in ACL region
Date: Wed, 4 Oct 2023 14:23:16 +0200	[thread overview]
Message-ID: <ZR1ZNPgcbRBa8uer@kernel.org> (raw)
In-Reply-To: <cover.1696330098.git.petrm@nvidia.com>

On Tue, Oct 03, 2023 at 01:25:25PM +0200, Petr Machata wrote:
> Amit Cohen writes:
> 
> For 12 key blocks in the A-TCAM, rules are split into two records, which
> constitute two lookups. The two records are linked using a
> "large entry key ID".
> 
> Due to a Spectrum-4 hardware issue, KVD entries that correspond to key
> blocks 0 to 5 of 12 key blocks will be placed in the same KVD pipe if they
> only differ in their "large entry key ID", as it is ignored. This results
> in a reduced scale, we can insert less than 20k filters and get an error:
> 
>     $ tc -b flower.batch
>     RTNETLINK answers: Input/output error
>     We have an error talking to the kernel
> 
> To reduce the probability of this issue, we can place key blocks with
> high entropy in blocks 0 to 5. The idea is to place blocks that are often
> changed in blocks 0 to 5, for example, key blocks that match on IPv4
> addresses or the LSBs of IPv6 addresses. Such placement will reduce the
> probability of these blocks to be same.
> 
> Mark several blocks with 'high_entropy' flag and place them in blocks 0
> to 5. Note that the list of the blocks is just a suggestion, I will verify
> it with architects.
> 
> Currently, there is a one loop that chooses which blocks should be used
> for a given list of elements and fills the blocks - when a block is
> chosen, it fills it in the region. To be able to control the order of
> the blocks, separate between searching blocks and filling them. Several
> pre-changes are required.
> 
> Patch set overview:
> Patch #1 marks several blocks with 'high_entropy' flag.
> Patches #2-#4 prepare the code for filling blocks at the end of the search.
> Patch #5 changes the loop to just choose the blocks and fill the blocks at
> the end.
> 
> Amit Cohen (5):
>   mlxsw: Mark high entropy key blocks
>   mlxsw: core_acl_flex_keys: Add a bitmap to save which blocks are
>     chosen
>   mlxsw: core_acl_flex_keys: Save chosen elements per block
>   mlxsw: core_acl_flex_keys: Save chosen elements in all blocks per
>     search
>   mlxsw: core_acl_flex_keys: Fill blocks with high entropy first
> 
>  .../mellanox/mlxsw/core_acl_flex_keys.c       | 64 +++++++++++++++++--
>  .../mellanox/mlxsw/core_acl_flex_keys.h       |  9 +++
>  .../mellanox/mlxsw/spectrum_acl_flex_keys.c   | 12 ++--
>  3 files changed, 72 insertions(+), 13 deletions(-)

For series,

Reviewed-by: Simon Horman <horms@kernel.org>


  parent reply	other threads:[~2023-10-04 12:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 11:25 [PATCH net-next 0/5] mlxsw: Control the order of blocks in ACL region Petr Machata
2023-10-03 11:25 ` [PATCH net-next 1/5] mlxsw: Mark high entropy key blocks Petr Machata
2023-10-03 11:25 ` [PATCH net-next 2/5] mlxsw: core_acl_flex_keys: Add a bitmap to save which blocks are chosen Petr Machata
2023-10-03 11:25 ` [PATCH net-next 3/5] mlxsw: core_acl_flex_keys: Save chosen elements per block Petr Machata
2023-10-03 11:25 ` [PATCH net-next 4/5] mlxsw: core_acl_flex_keys: Save chosen elements in all blocks per search Petr Machata
2023-10-03 11:25 ` [PATCH net-next 5/5] mlxsw: core_acl_flex_keys: Fill blocks with high entropy first Petr Machata
2023-10-04 12:23 ` Simon Horman [this message]
2023-10-06 10:10 ` [PATCH net-next 0/5] mlxsw: Control the order of blocks in ACL region 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=ZR1ZNPgcbRBa8uer@kernel.org \
    --to=horms@kernel.org \
    --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 \
    --cc=petrm@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.