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 17:55:38 +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>, <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).
> 
> 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?

It was merely a concern of not changing too much on something that is
already standard. Maybe I dont quite see how the APP interface can be
extended to accomodate for: pcp/dei, ingress/egress and trust. Lets
try to break it down:

  - pcp/dei: 
        this *could* be expressed in app->protocol and map 1:1 to the 
        pcp table entrise, so that 8*dei+pcp:priority. If I want to map 
        pcp 3, with dei 1 to priority 2, it would be encoded 11:2.

  - ingress/egress:
        I guess we need a selector for each? I notice that the mellanox
        driver uses the dcb_ieee_getapp_prio_dscp_mask_map and
        dcb_ieee_getapp_dscp_prio_mask_map for priority map and priority
        rewrite map, but these seems to be the same for both ingress and
        egress to me?

So far only subtle changes. Now how do you see trust going in. Can you
elaborate a little on the policy selector you mentioned?

/ Daniel