Re: Basic PCP/DEI-based queue classification

From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: "Allan W. Nielsen" <Allan.Nielsen@microchip.com>
Cc: Jakub Kicinski <kuba@kernel.org>, Petr Machata <petrm@nvidia.com>,
	"Daniel.Machon@microchip.com" <Daniel.Machon@microchip.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, 2 Sep 2022 13:32:19 +0000	[thread overview]
Message-ID: <20220902133218.bgfd2uaelvn6dsfa@skbuf> (raw)
In-Reply-To: <20220829075342.5ztd5hf4sznl7req@lx-anielsen>

On Mon, Aug 29, 2022 at 09:53:42AM +0200, Allan W. Nielsen wrote:
> Hi,
> 
> On 24.08.2022 17:54, Jakub Kicinski wrote:
> > For an uneducated maintainer like myself, how do embedded people look
> > at DCB? Only place I've seen it used is in RDMA clusers. I suggested
> > to Vladimir to look at DCBNL for frame preemption because it's the only
> > existing API we have that's vaguely relevant to HW/prio control but he
> > ended up going with ethtool.
> > No preference here, just trying to map it out in my head.
> 
> As I work toghether with Daniel, I'm biased. But I work a lot with
> embedded devices ;-)
> 
> I think this feature belong in DCB simply because DCB already have the
> related configurations (like the default prio, priority-flow-control
> etc), and it will be more logical for the user to find the PCP mapping
> in the same place.
> 
> I think that framepreemption should be in ethtool as it is partly
> defined in IEEE802.3 (the physical layer) and it is ethernet only
> technology.
> 
> /Allan

My explanation given to Jakub at the time was that I don't quite
understand what should belong to dcbnl and what shouldn't.
https://lore.kernel.org/netdev/20220523224943.75oyvbxmyp2kjiwi@skbuf/

From my perspective it's an inconvenience that dcbnl exists as a
separate kernel subsystem and isn't converged with the ethtool
genetlink.

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)?