Hi Jacub,

On Wed, 2022-11-02 at 18:28 -0700, Jakub Kicinski wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe

On Wed, 2 Nov 2022 14:11:37 +0100 Steen Hegelund wrote:

quoted

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.

Yes, so far I have only added the IS2 VCAP, but there are 3 more that I am
planning to to add, and they have very different capabilities in terms of keys
and actions, so I think it makes good sense to keep them in separate chains.

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).

Understood.

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 :)

It does, thanks!

I been fireing up a QEMU instance so I have been able to test my understanding,
and it looks like I now have the same experience when I test the same rule there
and in the hardware of Sparx5.

BR
Steen