Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 2 Nov 2022 18:28:43 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Steen Hegelund <steen.hegelund@microchip.com>
Cc:     Casper Andersson <casper.casan@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        <UNGLinuxDriver@microchip.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Russell King <rmk+kernel@armlinux.org.uk>,
        "Wan Jiabing" <wanjiabing@vivo.com>,
        Nathan Huckleberry <nhuck@google.com>,
        <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        Daniel Machon <daniel.machon@microchip.com>,
        Horatiu Vultur <horatiu.vultur@microchip.com>,
        Lars Povlsen <lars.povlsen@microchip.com>,
        Jiri Pirko <jiri@resnulli.us>
Subject: Re: [PATCH net-next v2 2/5] net: microchip: sparx5: Adding more tc
 flower keys for the IS2 VCAP
Message-ID: <20221102182843.6d14c7ed@kernel.org>
In-Reply-To: <e9d662682b00a976ad1dedf361a18b5f28aac8fb.camel@microchip.com>
References: <20221028144540.3344995-1-steen.hegelund@microchip.com>
        <20221028144540.3344995-3-steen.hegelund@microchip.com>
        <20221031103747.uk76tudphqdo6uto@wse-c0155>
        <51622bfd3fe718139cece38493946c2860ebdf77.camel@microchip.com>
        <20221031184128.1143d51e@kernel.org>
        <741b628857168a6844b6c2e0482beb7df9b56520.camel@microchip.com>
        <20221101084925.7d8b7641@kernel.org>
        <e9d662682b00a976ad1dedf361a18b5f28aac8fb.camel@microchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2 Nov 2022 14:11:37 +0100 Steen Hegelund wrote:
> I have sent a version 4 of the series, but I realized after sending it, that I
> was probably not understanding the implications of what you were saying
> entirely.
> 
> As far as I understand it now, I need to have a matchall rule that does a goto
> from chain 0 (as this is where all traffic processing starts) to my first IS2
> VCAP chain and this rule activates the IS2 VCAP lookup.
> 
> Each of the rules in this VCAP chain need to point to the next chain etc.
> 
> If the matchall rule is deleted the IS2 VCAP lookups should be disabled as there
> is no longer any way to reach the VCAP chains.
> 
> Does that sound OK?

It does as far as I understand.

I haven't grasped what the purpose of using multiple chains is in 
case of your design. IIRC correctly other drivers use it for instance
to partition TCAMs with each chain having a different set of fields it
can match on. But I don't see templates used in sparx5.

In general in TC offloads you can reject any configuration you can't
(or choose not to) support, and make up your own constraints (e.g. only
specific priority or chain values are supported).

But for a "target" ruleset, i.e. ruleset comprised fully of rules you
do offload - the behavior of executing that ruleset in software and in
the device must be the same.

Dunno if that helps :)