Re: [PATCH net-next 0/4] net/sched: cls_api: Support hardware miss to tc action

On Wed, Jan 18, 2023 at 4:27 PM Paul Blakey [off-list ref] wrote:

On 18/01/2023 14:54, Jamal Hadi Salim wrote:

quoted

On Tue, Jan 17, 2023 at 9:48 AM Paul Blakey [off-list ref] wrote:

quoted

On 17/01/2023 15:40, Jamal Hadi Salim wrote:

[..]

quoted

Can you maybe post an example of such a working example in your commit message
with stats?
You showed a candidate scenario that could be sorted but not a running example.

Sure Ill give it as full example in v3.

I saw your latest - I meant an example with tc -s as well to show
stats so we can see
hw vs sw stats.

quoted

Yeah, that was initially confusing when i read the commit log. It sounded
like action continue == action pipe (because it continues to the next action
in the action graph).
Maybe fix the commit to be clearer.

I don't think I mentioned it in the cover letter/commits, or did I miss
it ?

It's clearer in the latest commit.

quoted

Let me give a longer explanation.
The key i believe is understanding the action dependency. In my mind
there are 3 levels of
complexity for assumed ordering of actions A, B, C:

1) The simplest thing is to assume all-or-nothing (which is what we
have done so far in tc);
IOW if not all of A, B, C can be offloaded then we dont offload. >
2) next level of complexity is assuming that A MUST occur before B
which MUST occur before C.
Therefore on ingress you can offload part of that graph depending on
your hardware capability.
Example: On ingress A, B offloaded and then "continue" to C in s/w if
your hardware supports
only offloading A and B but not C. You do the reverse of that graph
for egress offload.

This is actually the case we want support in this patchset.
Assuming a tc filter has action A , action CT, action B.
If hardware finds that it can't do CT action in hardware (for example
for a new connection), but we already did action A, we want to continue
executing to "action CT, action B" in sw.

We can use it for partial offload of the action list, but for now it
will be used for supporting tuple rewrite action followed by action ct
such as in the example in the cover letter.

Ok. Part of the challenge here is also you are assuming that the rule is
both skip_sw and skip_hw which may simplify things but also adds to the
workaround complexity.
If i was a "smart user" i would split this into two: one that has
skip_sw and the
other that has skip_hw.

quoted

3) And your case is even more complex because you have a lot more
knowledge that infact
there is no action dependency and you can offload something in the
middle like B.
So i believe you are solving a harder problem than #2 which is what
was referring to in
my earlier email.

This is something we currently do but is "transparent" to the user.
If we have action A, action CT, action B, where A/B != CT and A doesn't
affect CT result (no dependency), we reorder it internally as action CT,
action A, action B. Then if we can't do CT in hardware, we didn't do A,
and can continue in sw to re-execute the filter and actions.

If there is no action dependency then let driver take care of the
details as we currently do we mlx5.

I think that is a fitting abstraction. The driver with enough knowledge of the
hw can do the necessary transforms.

cheers,
jamal