Re: [PATCH net 0/8] Add support for two classes of VCAP rules

[Steen Hegelund <steen.hegelund@microchip.com>]

Hi Paolo,

On Thu, 2022-12-22 at 15:22 +0100, Paolo Abeni wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> Hello,
> On Wed, 2022-12-21 at 14:25 +0100, Steen Hegelund wrote:
> > This adds support for two classes of VCAP rules:
> > 
> > - Permanent rules (added e.g. for PTP support)
> > - TC user rules (added by the TC userspace tool)
> > 
> > For this to work the VCAP Loopups must be enabled from boot, so that the
> > "internal" clients like PTP can add rules that are always active.
> > 
> > When the TC tool add a flower filter the VCAP rule corresponding to this
> > filter will be disabled (kept in memory) until a TC matchall filter creates
> > a link from chain 0 to the chain (lookup) where the flower filter was
> > added.
> > 
> > When the flower filter is enabled it will be written to the appropriate
> > VCAP lookup and become active in HW.
> > 
> > Likewise the flower filter will be disabled if there is no link from chain
> > 0 to the chain of the filter (lookup), and when that happens the
> > corresponding VCAP rule will be read from the VCAP instance and stored in
> > memory until it is deleted or enabled again.
> 
> Despite the 'net' target, this looks really like net-next material as
> most patches look like large refactor. I see there are a bunch of fixes
> in patches 3-8, but quite frankly it's not obvious at all what the
> refactors/new features described into the commit messages themself
> really fix.

Yes the patches 3-8 is the response to Michael Walles observations on LAN966x
and Jakubs Kicinski comment (see link), but the description in the commits may
not be that clear, in the sense that they do not state one-to-one what the
mitigation is.

See https://lore.kernel.org/netdev/20221209150332.79a921fd@kernel.org/

So essentially this makes it possible to have rules that are always in the VCAP
HW (to make the PTP feature work), even before the TC chains have been
established (which was the problem that Michael encountered).

I still think this a net submission, since it fixes the problem that was
observed in the previous netnext window.

But I will rephrase the reasoning in a V2 to hopefully make that more
understandable.

If you still think it is better to post this in the upcoming net-next window, I
am also OK with that.

> 
> I suggest to move this series to net-next (and thus repost after Jan
> 2), unless you come-up with some good reasons to keep it in net.
> 
> Thanks,
> 
> Paolo
> 

BR
Steen