netdev - Re: [PATCH net-next v6 5/9] net: dsa: microchip: add support for different DCB app configurations

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: <20240411113902.gh7hfivwdwdzzqea@skbuf>
Date: Thu, 11 Apr 2024 14:39:02 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Woojung Huh <woojung.huh@...rochip.com>, Andrew Lunn <andrew@...n.ch>,
	Arun Ramadoss <arun.ramadoss@...rochip.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	David Ahern <dsahern@...nel.org>, linux-kernel@...r.kernel.org,
	UNGLinuxDriver@...rochip.com, Eric Dumazet <edumazet@...gle.com>,
	Willem de Bruijn <willemb@...gle.com>, kernel@...gutronix.de,
	Søren Andersen <san@...v.dk>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v6 5/9] net: dsa: microchip: add support for
 different DCB app configurations

On Thu, Apr 11, 2024 at 08:48:04AM +0200, Oleksij Rempel wrote:
> > No, I think we _need_ the thing to be configurable, and not try so hard
> > with the ieee8021q helpers to hardcode things just right in the kernel.
> 
> Yes, I agree with you.
> 
> ieee8021q helpers are not the attempt to avoid the work needed to
> implement global DSCP configuration. The interface is still needed and
> we need to agree on how it should be implemented.
> 
> The problem which I try to address with ieee8021q helpers are initial
> defaults. KSZ8 and KSZ9 families of switches have different initial
> defaults. So, if i need to align defaults for this driver, why not to
> provide default which are reusable for every one?

Yeah, I don't know. "Don't trust DSCP" is not a good default?
Although at the same time I do realize that my own position is not
justified by my own actions (my drivers do trust VLAN PCP by default,
and the mapping is hardcoded and not configurable).

> > Have you tried the obvious: "every time there is a change to the global
> > DSCP mapping table, push the change into the dcbnl app table of all user
> > netdevs, so that the user becomes aware of what happens"? Kernel drivers
> > can do that, through direct calls to dcb_ieee_setapp(). DSA does it too,
> > to probe the initial QoS configuration of the ports and push it to the
> > application priority tables.
> 
> Hm... what interface should be used for the global DSCP mapping table?

Not any different than if it was per port... Just access the global DSCP
mapping table per port, and the kernel updates the table for every other
user port. That was my idea.