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] [day] [month] [year] [list]

Date:   Fri, 9 Sep 2022 12:11:50 +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 07:57:08PM +0000, Daniel.Machon@...rochip.com wrote:
> 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?

No, I don't think it's a real problem. I think it can be reasonably seen
as a per-VLAN override of the port-based default.

> > 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.

Ok, I'll take a look at what your implementation proposes.