From: Petr Machata <petrm@nvidia•com>
To: <Daniel.Machon@microchip•com>
Cc: <petrm@nvidia•com>, <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>, <roopa@nvidia•com>
Subject: Re: Basic PCP/DEI-based queue classification
Date: Wed, 24 Aug 2022 11:45:36 +0200 [thread overview]
Message-ID: <87pmgpki9v.fsf@nvidia.com> (raw)
In-Reply-To: <YwXXqB64QLDuKObh@DEN-LT-70577>
<Daniel.Machon@microchip•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?
next prev parent reply other threads:[~2022-08-24 11:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 9:09 Basic PCP/DEI-based queue classification Daniel.Machon
2022-08-19 10:50 ` Petr Machata
2022-08-21 20:58 ` Daniel.Machon
2022-08-22 10:34 ` Petr Machata
2022-08-24 7:39 ` Daniel.Machon
2022-08-24 9:45 ` Petr Machata [this message]
2022-08-24 17:55 ` Daniel.Machon
2022-08-24 19:36 ` Petr Machata
2022-08-25 0:54 ` Jakub Kicinski
2022-08-26 18:11 ` Petr Machata
2022-08-29 7:53 ` Allan W. Nielsen
2022-09-02 13:32 ` Vladimir Oltean
2022-09-07 10:41 ` Daniel.Machon
2022-09-07 17:26 ` Vladimir Oltean
2022-09-07 19:57 ` Daniel.Machon
2022-09-08 8:03 ` Allan Nielsen - M31684
2022-09-08 11:18 ` Petr Machata
2022-09-08 12:01 ` Daniel.Machon
2022-09-09 12:11 ` Vladimir Oltean
2022-09-08 8:27 ` Petr Machata
2022-08-25 11:31 ` Daniel.Machon
2022-08-25 13:30 ` Petr Machata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pmgpki9v.fsf@nvidia.com \
--to=petrm@nvidia$(echo .)com \
--cc=Allan.Nielsen@microchip$(echo .)com \
--cc=Daniel.Machon@microchip$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=maxime.chevallier@bootlin$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=roopa@nvidia$(echo .)com \
--cc=thomas.petazzoni@bootlin$(echo .)com \
--cc=vinicius.gomes@intel$(echo .)com \
--cc=vladimir.oltean@nxp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox