Re: Basic PCP/DEI-based queue classification

[<Daniel.Machon@microchip.com>]

> On Wed, Sep 07, 2022 at 10:41:10AM +0000, Daniel.Machon@microchip.com wrote:
> > > Regarding the topic at hand, and the apparent lack of PCP-based
> > > prioritization in the software data path. VLAN devices have an
> > > ingress-qos-map and an egress-qos-map. How would prioritization done via
> > > dcbnl interact with those (who would take precedence)?
> >
> > Hi Vladimir,
> >
> > They shouldn't interact (at least this is my understanding).
> >
> > The ingress and egress maps are for vlan interfaces, and dcb operates
> > on physical interfaces (dcbx too). You cannot use dcbnl to do
> > prioritization for vlan interfaces.
> >
> > Anyway, I think much of the stuff in DCB is for hw offload only, incl. the
> > topic at hand. Is the APP table even consulted by the sw stack at all - I
> > dont think so (apart from drivers).
> 
> Not directly, but at least ocelot (or in fact felix) does set
> skb->priority based on the QoS class from the Extraction Frame Header.
> So the stack does end up consulting and meaningfully using something
> that was set based on the dcbnl APP table.
> 
> In this sense, for ocelot, there is a real overlap between skb->priority
> being initially set based on ocelot_xfh_get_qos_class(), and later being
> overwritten based on the QoS maps of a VLAN interface.

Right, so VLAN QoS maps currently takes precedence, if somebody would choose
to add a tagged vlan interface on-top of a physical interface with existing
PCP prioritization - is this a real problem, or just a question of configuration?

> The problem with the ingress-qos-map and egress-qos-map from 802.1Q that
> I see is that they allow for per-VID prioritization, which is way more
> fine grained than what we need. This, plus the fact that bridge VLANs
> don't have this setting, only termination (8021q) VLANs do. How about an
> ingress-qos-map and an egress-qos-map per port rather than per VID,
> potentially even a bridge_slave netlink attribute, offloadable through
> switchdev? We could make the bridge input fast path alter skb->priority
> for the VLAN-tagged code paths, and this could give us superior
> semantics compared to putting this non-standardized knob in the hardware
> only dcbnl.

This is a valid alternative solution to dcbnl, although this seems to be a 
much more complex solution, to something that is easily solved in dcbnl,
and actually is in-line with what dcbnl already does. On-top of this, the
notion of 'trust' has also been raised by this topic. It makes a lot of sense
to me to add APP selector trust and trust order to dcbnl. This is the solution 
that I have been implementing lately, and is ready for posting very soon.

/ Daniel