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]

Date:   Wed, 24 Aug 2022 11:45:36 +0200
From:   Petr Machata <petrm@...dia.com>
To:     <Daniel.Machon@...rochip.com>
CC:     <petrm@...dia.com>, <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>, <roopa@...dia.com>
Subject: Re: Basic PCP/DEI-based queue classification

<Daniel.Machon@...rochip.com> writes:

>> 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).

Nice, so you can actually implement the sparsity of dscp-prio map. And
since PCP is always second in order, you can backfill any unspecified
PCP values from the default priority, or 0, and it will be semantically
the same.

>> 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.

Yeah, I keep saying pcp-prio, but actually what I mean is (pcp,
dei)-prio. The standard likewise talks about DEI always in connection to
priority, I believe, nobody prioritizes on DEI alone.

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

The 802.1q DCB has APP selector at three bits. Even if the standard
decides to get more bits somewhere, it seems unlikely that they would
add very many, because how many different fields does one need to
prioritize on? So I would feel safe using a large value internally in
Linux. But yeah, it's a concern.

> 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?

I would like to have a line of sight to how things will be done. Not
everything needs to be implemented at once, but we have to understand
how to get there when we need to. At least for issues that we can
already foresee now, such as the DSCP / PCP / default ordering.

Adding the PCP rules as a new APP selector, and then expressing the
ordering as a "selector policy" or whatever, IMHO takes care of this
nicely.

But OK, let's talk about the "flexibility" bit that you mention: what
does this approach make difficult or impossible?