Re: Basic PCP/DEI-based queue classification

From: <Daniel.Machon@microchip.com>
To: <petrm@nvidia.com>
Cc: <netdev@vger.kernel.org>, <kuba@kernel.org>,
	<vinicius.gomes@intel.com>, <vladimir.oltean@nxp.com>,
	<thomas.petazzoni@bootlin.com>, <Allan.Nielsen@microchip.com>,
	<maxime.chevallier@bootlin.com>, <nikolay@nvidia.com>,
	<roopa@nvidia.com>
Subject: Re: Basic PCP/DEI-based queue classification
Date: Wed, 24 Aug 2022 07:39:25 +0000	[thread overview]
Message-ID: <YwXXqB64QLDuKObh@DEN-LT-70577> (raw)
In-Reply-To: <87v8qklbly.fsf@nvidia.com>

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