Date:   Thu, 25 Aug 2022 11:31:12 +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

> > 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.
> 
> Yep. In particular something like {sel=255, pid=11, prio=2}.
> 
> iproute2 "dcb" would obviously grow brains to let you configure this
> stuff semantically, so e.g.:
> 
> # dcb app replace dev X pcp-prio 3:3 3de:2 2:2 2de:1
> 
> >   - 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?
> 
> Ha, I was only thinking about prioritization, not about rewrite at all.
> 
> Yeah, mlxsw uses APP rules for rewrite as well. The logic is that if the
> network behind port X uses DSCP value D to express priority P, then
> packets with priority P leaving that port should have DSCP value of D.
> Of course it doesn't work too well, because there are 8 priorities, but
> 64 DSCP values. So mlxsw arbitrarily chooses the highest DSCP value.
> 
> The situation is similar with PCP, where there are 16 PCP+DEI
> combinations, but only 8 priorities.
> 
> So having a way to configure rewrite would be good. But then we are very
> firmly in the extension territory. This would basically need a separate
> APP-like object.
> 
> > So far only subtle changes. Now how do you see trust going in. Can you
> > elaborate a little on the policy selector you mentioned?
> 
> Sure. In my mind the policy is a array that describes the order in which
> APP rules are applied. "default" is implicitly last.
> 
> So "trust DSCP" has a policy of just [DSCP]. "Trust PCP" of [PCP].
> "Trust DSCP, then PCP" of [DSCP, PCP]. "Trust port" (i.e. just default)
> is simply []. Etc.
> 
> Individual drivers validate whether their device can implement the
> policy.
> 
> I expect most devices to really just support the DSCP and PCP parts, but
> this is flexible in allowing more general configuration in devices that
> allow it.
> 
> ABI-wise it is tempting to reuse APP to assign priority to selectors in
> the same way that it currently assigns priority to field values:
> 
> # dcb app replace dev X sel-prio dscp:2 pcp:1
> 
> But that feels like a hack. It will probably be better to have a
> dedicated object for this:
> 
> # dcb app-policy set dev X sel-order dscp pcp
> 
> This can be sliced in different ways that we can bikeshed to death
> later. Does the above basically address your request?

Yes, thanks for elaborating - I follow you now. Also, I agree that this 
could fit into APP.

I will prepare some patches for this soon and make sure to cc you. 
Initially I would like to add support for:

  - pcp/dei-prio mapping for ingress only. If things look good, we
    can add support for rewrite later. Any objections to this?

  - Support for trust ordering as a new dedicated object.

/ Daniel

Powered by blists - more mailing lists