[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220909121149.424ztw6lrfq5jann@skbuf>
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.
Powered by blists - more mailing lists