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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220217154259.f255cmrejxb7rlzt@skbuf>
Date:   Thu, 17 Feb 2022 17:42:59 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Petr Machata <petrm@...dia.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Ido Schimmel <idosch@...dia.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...dia.com>, f.fainelli@...il.com,
        vivien.didelot@...il.com
Subject: 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:
> >> 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?