From: Simon Horman <horms@kernel.org>
To: Marcin Szycik <marcin.szycik@linux.intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
przemyslaw.kitszel@intel.com, michal.swiatkowski@linux.intel.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-next 5/6] ice: Optimize switch recipe creation
Date: Fri, 28 Jun 2024 19:22:46 +0100 [thread overview]
Message-ID: <20240628182246.GE837606@kernel.org> (raw)
In-Reply-To: <96df3ad4-dd4b-409d-98ed-aa5c6173b579@linux.intel.com>
On Fri, Jun 28, 2024 at 03:39:27PM +0200, Marcin Szycik wrote:
>
>
> On 28.06.2024 14:44, Simon Horman wrote:
> > 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.
>
> Yeah... it is a bit of a revolution, and unfortunately I don't think much of
> if could be separated into other patches. Maybe functions like
> fill_recipe_template() and bookkeep_recipe() would be good candidates.
> If there will be another version, I'll try to separate some of it.
Understood. TBH, I couldn't think of a great way to split it either.
next prev parent reply other threads:[~2024-06-28 18:22 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
2024-06-28 13:39 ` [Intel-wired-lan] " Marcin Szycik
2024-06-28 18:22 ` Simon Horman [this message]
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=20240628182246.GE837606@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).