Message-ID: <87v8qklbly.fsf@nvidia.com>
Date:   Mon, 22 Aug 2022 12:34:25 +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>, <nikolay@...dia.com>,
        <roopa@...dia.com>
Subject: Re: Basic PCP/DEI-based queue classification


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

>> > In the old thread, Maxime has compiled a list of ways we can possibly offload
>> > the queue classification. However none of them is a good match for our purpose,
>> > for the following reasons:
>> >
>> >  - tc-flower / tc-skbedit: The filter and action scheme maps poorly to hardware
>> >    and would require one hardware-table entry per rule. Even less of a match
>> >    when DEI is also considered. These tools are well suited for advanced
>> >    classification, and not so much for basic per-port classification.
>> 
>> Yeah.
>> 
>> Offloading this is a pain. You need to parse out the particular shape of
>> rules (which is not a big deal honestly), and make sure the ordering of
>> the rules is correct and matches what the HW is doing. And tolerate any
>> ACL-/TCAM- like rules as well. And there's mismatch between how a
>> missing rule behaves in SW (fall-through) and HW (likely priority 0 gets
>> assigned).
>> 
>> And configuration is pain as well, because a) it's a whole bunch of
>> rules to configure, and b) you need to be aware of all the limitations
>> from the previous paragraph and manage the coexistence with ACL/TCAM
>> rules.
>> 
>> It's just not a great story for this functionality.
>> 
>> I wonder if a specialized filter or action would make things easier to
>> work with. Something like "matchall action dcb dscp foo bar priority 7".
>> 
>
> I really think that pcp mapping should not go into tc. It is just not 
> user-friendly at all, and I believe better alternatives exists.

"better" along the "more specialized, hence easier to configure" axis.
But DCB in particular doesn't address the SW datapath at all, and if you
want this sort of prioritization in SW, you have to fall back on flower
et.al. anyway.

> So a pcp mapping functionality could very well go into dcb as an extension,
> for the following reasons:
>
>  - dcb already contains non-standard extension (dcb-maxrate)

Yeah, and if the standard DCB ever gets maxrate knobs that are not 1:1
compatible with what we now have, we're in trouble.

Whatever new things is getting added, needs to be added in a way that
makes standard collisions very unlikely.

>  - Adding an extension (dcb-pcp?) for configuring the pcp tables of ieee-802.1q
>    seems to be in line with what dcb-app is doing with the app table. Now, the
>    app table and the pcp tables are different, but they are both inteded to map
>    priority to queue (dscp or pcp/dei).

(Not priority to queue, but header field values to priority. Queue
assignment is "dcb buffer prio-buffer" on ingress and "dcb ets prio-tc"
on egress.)

>  - default prio for non-tagged frames is already possible in dcb-app
>
>  - dscp priority mapping is also possible in dcb-app
>
>  - dcb already has the necessary data structures for mapping priority to queue 
>    (array parameter)
>
>  - Seems conventient to place the priority mapping in one place (dscp and pcp/dei).
>
> Any thoughts?

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.

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.

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


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.

Powered by blists - more mailing lists