From: Jens Emil Schulz Ostergaard <jensemil.schulzostergaard@microchip.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <horatiu.vultur@microchip.com>, <UNGLinuxDriver@microchip.com>,
<andrew+netdev@lunn.ch>, <davem@davemloft.net>,
<edumazet@google.com>, <pabeni@redhat.com>,
<daniel.machon@microchip.com>, <Steen.Hegelund@microchip.com>,
<kees@kernel.org>, <gustavoars@kernel.org>,
<robert.marko@sartura.hr>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH net-next v2 1/9] net: microchip: vcap: fix rule move for rules of coprime size
Date: Tue, 25 Aug 2026 12:34:08 +0200 [thread overview]
Message-ID: <cd8c7732d896bafe436204362bf5f20e3fddf3ed.camel@microchip.com> (raw)
In-Reply-To: <20260817211333.3633182-1-kuba@kernel.org>
On Mon, 2026-08-17 at 14:13 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: microchip: vcap: fix rule move for rules of coprime size
>
> This reworks the VCAP rule move logic so that insert and delete compute a
> single uniform address offset, aligned to the LCM of the rule sizes in the
> moved block, instead of per-rule "optimal" offsets. The goal is to keep the
> software rule addresses in sync with what the hardware move command does,
> which becomes necessary once rules of coprime sizes (2 and 3) appear with
> the LPM VCAP.
>
> One question about the delete algorithm description in the changelog.
>
> > On delete:
> >
> > 1. Initialize HW memory at the deleted rule's addresses before
> > moving, since the moved block may not fully cover them due to
> > padding.
> > 2. Reclaim any padding between rules in the block.
>
> [Severity: Low]
> Is step 2 accurate for the new implementation? As far as I can tell the
> padding that sits between rules inside the moved block is preserved, not
> reclaimed, because a single offset is applied to every rule in the block:
>
> drivers/net/ethernet/microchip/vcap/vcap_api.c:vcap_move_rules_sw() {
> list_for_each_entry_continue(pos, &admin->rules, list)
> pos->addr -= move->offset;
> }
>
> Since every rule in the block is shifted by the same move->offset, the gaps
> between rules within the block are structurally invariant across the move.
>
> What appears to be reclaimed is the deleted rule's own space plus the
> padding adjacent to its position, and only down to block_lcm granularity.
> In the delete path unaligned_offset is always negative (block_first->addr +
> block_first->size <= ri->addr <= base_addr), so the truncating branch is
> taken in vcap_move_from_block():
>
> drivers/net/ethernet/microchip/vcap/vcap_api.c:vcap_move_from_block() {
> unaligned_offset = (block_first->addr + block_first->size) - base_addr;
> if (unaligned_offset > 0)
> move->offset =
> ((unaligned_offset + (block_lcm - 1)) / block_lcm) *
> block_lcm;
> else
> move->offset = (unaligned_offset / block_lcm) * block_lcm;
> }
>
> Integer division truncating toward zero leaves up to block_lcm - 1 addresses
> of the gap unreclaimed at the boundary.
>
> Could the changelog wording be adjusted to describe what is actually
> reclaimed, for example the deleted rule's addresses plus adjacent padding,
> rounded down to the block LCM?
>
Yes I will update the commit message, this is poorly worded.
> > diff --git a/drivers/net/ethernet/microchip/vcap/vcap_api.c b/drivers/net/ethernet/microchip/vcap/vcap_api.c
> > index 788c0728d7636..75c2ca54fddd2 100644
> > --- a/drivers/net/ethernet/microchip/vcap/vcap_api.c
> > +++ b/drivers/net/ethernet/microchip/vcap/vcap_api.c
>
> [ ... ]
>
> > @@ -2106,12 +2108,63 @@ static u32 vcap_set_rule_id(struct vcap_rule_internal *ri)
> > return ri->data.id;
> > }
> >
> > +static void vcap_move_from_block(u32 base_addr,
> > + struct vcap_rule_internal *block_first,
> > + struct vcap_rule_internal *block_last,
> > + int block_lcm, struct vcap_rule_move *move)
> > +{
> > + int unaligned_offset;
> > +
> > + if (!block_first || !block_last)
> > + return;
> > +
> > + move->addr = block_last->addr;
> > + move->count = block_first->addr + block_first->size - block_last->addr;
> > + /* Integer division rounds toward zero. We want to round toward +inf
> > + * for the positive case (insertion) to ensure enough room.
> > + */
> > + unaligned_offset = (block_first->addr + block_first->size) - base_addr;
> > + if (unaligned_offset > 0)
> > + move->offset =
> > + ((unaligned_offset + (block_lcm - 1)) / block_lcm) *
> > + block_lcm;
> > + else
> > + move->offset = (unaligned_offset / block_lcm) * block_lcm;
> > +}
> > +
> > +static void vcap_move_rules_sw(struct vcap_admin *admin,
> > + struct vcap_rule_internal *pos,
> > + struct vcap_rule_move const *move)
> > +{
> > + if (move->count == 0 || move->offset == 0)
> > + return;
> > +
> > + list_for_each_entry_continue(pos, &admin->rules, list)
> > + pos->addr -= move->offset;
> > +}
>
> [ ... ]
> --
> pw-bot: cr
next prev parent reply other threads:[~2026-08-25 10:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 11:20 [PATCH net-next v2 0/9] net: sparx5: add L3 unicast routing offload Jens Emil Schulz Østergaard
2026-08-10 11:20 ` [PATCH net-next v2 1/9] net: microchip: vcap: fix rule move for rules of coprime size Jens Emil Schulz Østergaard
2026-08-17 21:13 ` Jakub Kicinski
2026-08-25 10:34 ` Jens Emil Schulz Ostergaard [this message]
2026-08-10 11:20 ` [PATCH net-next v2 2/9] net: microchip: vcap: add lpm vcap to autogen vcap api Jens Emil Schulz Østergaard
2026-08-10 11:20 ` [PATCH net-next v2 3/9] net: microchip: vcap: make vcap actionset decoding type_id aware Jens Emil Schulz Østergaard
2026-08-17 21:13 ` Jakub Kicinski
2026-08-25 10:35 ` Jens Emil Schulz Ostergaard
2026-08-10 11:20 ` [PATCH net-next v2 4/9] net: microchip: vcap: expose helpers in vcap api and update debugfs Jens Emil Schulz Østergaard
2026-08-17 21:13 ` Jakub Kicinski
2026-08-25 11:09 ` Jens Emil Schulz Ostergaard
2026-08-10 11:20 ` [PATCH net-next v2 5/9] net: sparx5: add l3 routing registers Jens Emil Schulz Østergaard
2026-08-10 11:20 ` [PATCH net-next v2 6/9] net: sparx5: vcap: add lpm vcap implementation Jens Emil Schulz Østergaard
2026-08-17 21:13 ` Jakub Kicinski
2026-08-25 12:19 ` Jens Emil Schulz Ostergaard
2026-08-10 11:20 ` [PATCH net-next v2 7/9] net: sparx5: add L3 router infrastructure and leg management Jens Emil Schulz Østergaard
2026-08-17 21:13 ` Jakub Kicinski
2026-08-26 14:04 ` Jens Emil Schulz Ostergaard
2026-08-10 11:20 ` [PATCH net-next v2 8/9] net: sparx5: add L3 FIB, nexthop and neighbour entry management Jens Emil Schulz Østergaard
2026-08-17 21:13 ` Jakub Kicinski
2026-08-27 13:48 ` Jens Emil Schulz Ostergaard
2026-08-10 11:20 ` [PATCH net-next v2 9/9] net: sparx5: add neighbour event handling for L3 routing Jens Emil Schulz Østergaard
2026-08-17 21:14 ` Jakub Kicinski
2026-08-27 14:44 ` Jens Emil Schulz Ostergaard
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=cd8c7732d896bafe436204362bf5f20e3fddf3ed.camel@microchip.com \
--to=jensemil.schulzostergaard@microchip.com \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew+netdev@lunn.ch \
--cc=daniel.machon@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gustavoars@kernel.org \
--cc=horatiu.vultur@microchip.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robert.marko@sartura.hr \
/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.