Netdev List
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox