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

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

[..]

quoted

Question: How does someone adding these rules tell whether some of
the actions are offloaded and some are not? If i am debugging this because
something was wrong I would like to know.

Currently by looking at the per action hw stats, and if they are
advancing. This is the same now with filters and the CT action for
new connections (driver reports offload, but it means that only for
established connections).

I think that may be sufficient given we use the same technique for
filter offload.
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.

quoted

It will be an action continue for a scenario where (on ingress) you have
action A from A,B,C being offloaded and B,C is in s/w - the fw filter
will have the
B,C and flower can have A offloaded.
Yes, someone/thing programming these will have to know that only A can
be offloaded
in that graph.

I meant using continue to go to next tc priority "as in "action A action
continue" but I'm not sure about the actual details of fully supporting
this as its not the purpose of this patch, but maybe will lead there.

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.

quoted

Ok, so would this work for the scenario I described above? i.e A,B, C where
A is offloaded but not B, C?

You mean the reorder? we reorder the CT action first if all other
actions are supported, so we do all or nothing.

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.

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.

The way these things are typically solved is to have a "dependency"
graph that can be
programmed depending on h/w offload capability and then you can make a decision
whether (even in s/w) to allow A,B,C vs C,A,B for example.

Note: I am not asking for the change - but would be nice to have and I
think over time
generalize. I am not sure how other vendors would implement this today.

Note: if i have something smart in user space - which is what i was
referring to earlier
(with mention of skbmark) I can achieve these goals without any kernel
code changes
but like i said i understand the operational simplicity by putting
things in the kernel.

cheers,
jamal