netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Marcin Szycik <marcin.szycik@linux.intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	michal.swiatkowski@linux.intel.com, przemyslaw.kitszel@intel.com
Subject: Re: [PATCH iwl-next 5/6] ice: Optimize switch recipe creation
Date: Fri, 28 Jun 2024 13:44:09 +0100	[thread overview]
Message-ID: <20240628124409.GD783093@kernel.org> (raw)
In-Reply-To: <20240618141157.1881093-6-marcin.szycik@linux.intel.com>

On Tue, Jun 18, 2024 at 04:11:56PM +0200, Marcin Szycik wrote:
> Currently when creating switch recipes, switch ID is always added as the
> first word in every recipe. There are only 5 words in a recipe, so one
> word is always wasted. This is also true for the last recipe, which stores
> result indexes (in case of chain recipes). Therefore the maximum usable
> length of a chain recipe is 4 * 4 = 16 words. 4 words in a recipe, 4
> recipes that can be chained (using a 5th one for result indexes).
> 
> Current max size chained recipe:
> 0: smmmm
> 1: smmmm
> 2: smmmm
> 3: smmmm
> 4: srrrr
> 
> Where:
> s - switch ID
> m - regular match (e.g. ipv4 src addr, udp dst port, etc.)
> r - result index
> 
> Switch ID does not actually need to be present in every recipe, only in one
> of them (in case of chained recipe). This frees up to 8 extra words:
> 3 from recipes in the middle (because first recipe still needs to have
> switch ID), and 5 from one extra recipe (because now the last recipe also
> does not have switch ID, so it can chain 1 more recipe).
> 
> Max size chained recipe after changes:
> 0: smmmm
> 1: Mmmmm
> 2: Mmmmm
> 3: Mmmmm
> 4: MMMMM
> 5: Rrrrr
> 
> Extra usable words available after this change are highlighted with capital
> letters.
> 
> Changing how switch ID is added is not straightforward, because it's not a
> regular lookup. Its FV index and mask can't be determined based on protocol
> + offset pair read from package and instead need to be added manually.
> 
> Additionally, change how result indexes are added. Currently they are
> always inserted in a new recipe at the end. Example for 13 words, (with
> above optimization, switch ID being one of the words):
> 0: smmmm
> 1: mmmmm
> 2: mmmxx
> 3: rrrxx
> 
> Where:
> x - unused word
> 
> In this and some other cases, the result indexes can be moved just after
> last matches because there are unused words, saving one recipe. Example
> for 13 words after both optimizations:
> 0: smmmm
> 1: mmmmm
> 2: mmmrr
> 
> Note how one less result index is needed in this case, because the last
> recipe does not need to "link" to itself.
> 
> There are cases when adding an additional recipe for result indexes cannot
> be avoided. In that cases result indexes are all put in the last recipe.
> Example for 14 words after both optimizations:
> 0: smmmm
> 1: mmmmm
> 2: mmmmx
> 3: rrrxx
> 
> With these two changes, recipes/rules are more space efficient, allowing
> more to be created in total.
> 
> Co-developed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>

I appreciate the detailed description above, it is very helpful.
After a number of readings of this patch - it is complex -
I was unable to find anything wrong. And I do like both the simplification
and better hw utilisation that this patch (set) brings.

So from that perspective:

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

I would say, however, that it might have been easier to review
if somehow this patch was broken up into smaller pieces.
I appreciate that, in a sense, that is what the other patches
of this series do. But nonetheless... it is complex.

...

  reply	other threads:[~2024-06-28 12:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18 14:11 [PATCH iwl-next 0/6] Switch API optimizations Marcin Szycik
2024-06-18 14:11 ` [PATCH iwl-next 1/6] ice: Remove unused struct ice_prot_lkup_ext members Marcin Szycik
2024-06-28 12:40   ` Simon Horman
2024-06-18 14:11 ` [PATCH iwl-next 2/6] ice: Remove reading all recipes before adding a new one Marcin Szycik
2024-06-28 12:41   ` Simon Horman
2024-06-18 14:11 ` [PATCH iwl-next 3/6] ice: Simplify bitmap setting in adding recipe Marcin Szycik
2024-06-19 14:34   ` [Intel-wired-lan] " Alexander Lobakin
2024-06-18 14:11 ` [PATCH iwl-next 4/6] ice: remove unused recipe bookkeeping data Marcin Szycik
2024-06-28 12:41   ` Simon Horman
2024-06-18 14:11 ` [PATCH iwl-next 5/6] ice: Optimize switch recipe creation Marcin Szycik
2024-06-28 12:44   ` Simon Horman [this message]
2024-06-28 13:39     ` [Intel-wired-lan] " Marcin Szycik
2024-06-28 18:22       ` Simon Horman
2024-06-28 13:56     ` Przemek Kitszel
2024-06-28 18:25       ` Simon Horman
2024-06-18 14:11 ` [PATCH iwl-next 6/6] ice: Remove unused members from switch API Marcin Szycik
2024-06-28 12:44   ` Simon Horman

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=20240628124409.GD783093@kernel.org \
    --to=horms@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=marcin.szycik@linux.intel.com \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.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).