netdev - Re: Basic PCP/DEI-based queue classification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Sep 2022 17:26:14 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     "Daniel.Machon@...rochip.com" <Daniel.Machon@...rochip.com>
CC:     "Allan.Nielsen@...rochip.com" <Allan.Nielsen@...rochip.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "petrm@...dia.com" <petrm@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        "maxime.chevallier@...tlin.com" <maxime.chevallier@...tlin.com>,
        "roopa@...dia.com" <roopa@...dia.com>
Subject: Re: Basic PCP/DEI-based queue classification

On Wed, Sep 07, 2022 at 10:41:10AM +0000, Daniel.Machon@...rochip.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.

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.