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

[Vladimir Oltean <olteanv@gmail.com>]

Hi Petr,

On Fri, Feb 11, 2022 at 07:24:34PM +0100, Petr Machata wrote:
> >> 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".
> 
> >> 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.
> 
> > 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?