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]
Message-ID: <Yxj5smlnHEMn0sq2@DEN-LT-70577>
Date:   Wed, 7 Sep 2022 19:57:08 +0000
From:   <Daniel.Machon@...rochip.com>
To:     <vladimir.oltean@....com>
CC:     <Allan.Nielsen@...rochip.com>, <kuba@...nel.org>,
        <petrm@...dia.com>, <netdev@...r.kernel.org>,
        <vinicius.gomes@...el.com>, <thomas.petazzoni@...tlin.com>,
        <maxime.chevallier@...tlin.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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ