linux-kernel - 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: <20240621103144.300a2c89@wsk>
Date: Fri, 21 Jun 2024 10:31:44 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Vladimir Oltean <olteanv@...il.com>
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

Hi Vladimir,

> 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.
> 

Thanks for the explanation.

> 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.

IMHO, the above problem is not related to the patch send here. It shall
be addressed with new patch series.

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

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped