Re: [RFC PATCH net-next 1/2] net: dsa: allow setting port-based QoS priority using tc matchall skbedit

Hi Petr,

On Fri, Feb 11, 2022 at 07:24:34PM +0100, Petr Machata wrote:

quoted

quoted

Now I don't understand DSA at all, but given a chip with fancy defaults,
for the DCB interface in particular, it would make sense to me to have
two ops. As long as there are default-prio entries, a "set default
priority" op would get invoked with the highest configured default
priority. When the last entry disappears, an "unset" op would be called.

I don't understand this comment, sorry. I don't know what's a "chip with
fancy defaults".

I'm referring here to Andrew's "I guess any switch [...] defaults to
something [...] a bit smarter than everything goes to traffic class 0".

quoted

quoted

Not sure what DSA does with ACLs, but it's not clear to me how TC-based
prioritization rules coexist with full blown ACLs. I suppose the prio
stuff could live on chain 0 and all actions would be skbedit prio pipe
goto chain 1 or something. And goto chain 0 is forbidden, because chain
0 is special. Or maybe the prioritization stuff lives on a root qdisc
(but no, we need it for ingress packets...) One way or another it looks
hairy to dissect and offload accurately IMHO.

There's nothing to understand about the DSA core at all, it has no
saying in how prioritization or TC rules are configured, that is left
down to the hardware driver.

To make sure we use the same terminology, when you say "how TC-based
prioritization rules coexist with full blown ACLs", you mean
trap/drop/redirect by ACLs, right?

Yeah. But also simple stuff, like skbedit priority, but with complex
matching. Think flower match on a side chain that only gets invoked when
another flower match hits.

quoted

So the ocelot driver has a programmable, fixed pipeline of multiple
ingress stages (VCAP IS1 for VLAN editing and advanced QoS classification)
and egress stages (VCAP ES0 for egress VLAN rewriting). We model the
entire TCAM subsystem using one chain per TCAM lookup, and force gotos
from the current stage to the next. See
tools/testing/selftests/drivers/net/ocelot/tc_flower_chains.sh for the
intended usage model.

Now, that's all for advanced QoS classification, not for port-based
default, VLAN PCP and IP DSCP. My line of thinking is that we could do
the latter via dcb-app, and leave the former where it is (skbedit with
tc-flower), and they'd coexist just fine, right?

That's what we do. I don't like it very much, because DCB is this odd
HW-centric thing that you can't run on bridged veths. But unfortunately
TC filter configuration that describes the dumb stuff and then follows
up with more of the complex stuff that needs to happen _as well_, seems
like it would be a mess to both dissect in the driver and use on the
command line.

Maybe we need a multi-stage clsact qdisc, or something like that... ^o^

I see dcb_ieee_setapp() can be used to preload the Application Priority
Table with information that reflects the port's configuration.

I'm just wondering - do you have any idea why the Application Priority TLV
doesn't have a way to describe a mapping between VLAN PCP and priority?
What can I use to also describe that?