Re: Basic PCP/DEI-based queue classification

From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: "Daniel.Machon@microchip.com" <Daniel.Machon@microchip.com>
Cc: "Allan.Nielsen@microchip.com" <Allan.Nielsen@microchip.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"petrm@nvidia.com" <petrm@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"vinicius.gomes@intel.com" <vinicius.gomes@intel.com>,
	"thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
	"maxime.chevallier@bootlin.com" <maxime.chevallier@bootlin.com>,
	"roopa@nvidia.com" <roopa@nvidia.com>
Subject: Re: Basic PCP/DEI-based queue classification
Date: Fri, 9 Sep 2022 12:11:50 +0000	[thread overview]
Message-ID: <20220909121149.424ztw6lrfq5jann@skbuf> (raw)
In-Reply-To: <Yxj5smlnHEMn0sq2@DEN-LT-70577>

On Wed, Sep 07, 2022 at 07:57:08PM +0000, Daniel.Machon@microchip.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.