netdev - Re: [PATCH v2 net-next] net: dsa: Allow only up to two HSR HW offloaded ports for KSZ9477

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: <20240620143306.f6x25tqksatccqwf@skbuf>
Date: Thu, 20 Jun 2024 17:33:06 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Lukasz Majewski <lukma@...x.de>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Oleksij Rempel <o.rempel@...gutronix.de>, Tristram.Ha@...rochip.com,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Simon Horman <horms@...nel.org>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	"Ricardo B. Marliere" <ricardo@...liere.net>,
	Casper Andersson <casper.casan@...il.com>,
	linux-kernel@...r.kernel.org,
	Woojung Huh <woojung.huh@...rochip.com>,
	UNGLinuxDriver@...rochip.com, Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH v2 net-next] net: dsa: Allow only up to two HSR HW
 offloaded ports for KSZ9477

On Thu, Jun 20, 2024 at 03:28:19PM +0200, Lukasz Majewski wrote:
> I don't have xrs700x to test. Shall I spend time on fixing some
> perceived issue for IC which I don't have?
> 
> Maybe somebody (like manufacturer or _real_ user) with xrc700x shall
> test the code and provide feedback?

One of the basic premises when you introduce a new core feature with
offload potential is that you consider how the existing drivers will
handle it. Either they do something reasonable already (great but rarely
happens), or they refuse offloading the new feature until, as you say,
the developer or real user has a look at what would be needed. Once you
get things to that stage, that would be, in my mind, the cutoff point
between the responsibility of who's adding the core feature and who's
interested in it on random other hardware.

Sometimes, the burden of checking/modifying all existing offloading
drivers before adding a new feature is so high, that some offloading API
is developed with an opt-in rather than opt-out model. AKA, rather than
the configuration being directly given to you and you rejecting what you
don't support, the core first assumed you can't offload anything, and
you have to set a bit from the driver to announce the core that you can.
qdisc_offload_query_caps() is an implementation of this model, though
I'm pretty sure the NETDEV_CHANGEUPPER notifier doesn't have anything
similar currently.

That being said, I think the responsibility falls on your side here,
given that you introduced a new HSR port type and offload drivers still
implicitly think it's a ring port, because there's no API to tell them
otherwise.

This is not to take away from the good things you _have_ done already.