netdev - Re: Basic PCP/DEI-based queue classification

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YwXXqB64QLDuKObh@DEN-LT-70577>
Date:   Wed, 24 Aug 2022 07:39:25 +0000
From:   <Daniel.Machon@...rochip.com>
To:     <petrm@...dia.com>
CC:     <netdev@...r.kernel.org>, <kuba@...nel.org>,
        <vinicius.gomes@...el.com>, <vladimir.oltean@....com>,
        <thomas.petazzoni@...tlin.com>, <Allan.Nielsen@...rochip.com>,
        <maxime.chevallier@...tlin.com>, <nikolay@...dia.com>,
        <roopa@...dia.com>
Subject: Re: Basic PCP/DEI-based queue classification

> How do the pcp-prio rules work with the APP rules? There's the dscp-prio
> sparse table, then there will be the pcp-prio (sparse?) table, what
> happens if a packet arrives that has both headers? In Spectrum switches,
> DSCP takes precedence, but that may not be universal.

In lan966x and sparx5 switches, dscp also takes precendence over pcp, in
default mode. Wrt. trust: DSCP mapping can be enabled/disabled and trusted
per-dscp-value. PCP mapping can be enabled/disabled, but not trusted
per-pcp-value. If DSCP mapping is enabled, and the DSCP value is trusted,
then DSCP mapping is used, otherwise PCP (if tagged).

> 
> It looks like adding "PCP" to APP would make the integration easiest.
> Maybe we could use an out-of-band sel value for the selector, say 256,
> to likely avoid incompatible standardization?
> 
> Then the trust level can be an array of selectors that shows how the
> rules should be applied. E.g. [TCPUDP, DSCP, PCP]. Some of these
> configurations are not supported by the HW and will be bounced by the
> driver.

We also need to consider the DEI bit. And also whether the mapping is for
ingress or egress.

This suddenly becomes quite an intrusive addition to an already standardized
APP interface.

As I hinted earlier, we could also add an entirely new PCP interface 
(like with maxrate), this will give us a bit more flexibility and will 
not crash with anything. This approach will not give is trust for DSCP, 
but maybe we can disregard this and go with a PCP solution initially?

> 
> (Am I missing something in the standard? It doesn't seem to deal with
> how the APP rules are actually applied at all.)

No, this part is somewhat vague.

> 
> 
> Another issue: DCB APP is a sparse table. There's a question of what
> should happen for the e.g. DSCP values that don't have an APP entry.
> Logically I think they should "fall through" to other APP rules as per
> the selector array.
> 
> Thing is, ASICs probably don't support this "fall-through" feature. So I
> don't know what to do with this. Kinda brings back some of that TC
> complexity, where you need to add all the rules, otherwise the HW can't
> be compatibly configured.

True. Let this be a PCP mapping that is inteded for the hw datapath only.