netdev - Re: [PATCH v2 net-next 0/2] net: dsa: mv88e6xxx: Improve indirect addressing performance

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Jan 2022 17:10:43 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     David Laight <David.Laight@...lab.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 0/2] net: dsa: mv88e6xxx: Improve indirect
 addressing performance

On Fri, Jan 28, 2022 at 04:58:02PM +0100, Tobias Waldekranz wrote:
> On Fri, Jan 28, 2022 at 14:10, David Laight <David.Laight@...LAB.COM> wrote:
> > From: Tobias Waldekranz
> >> Sent: 28 January 2022 10:50
> >> 
> >> The individual patches have all the details. This work was triggered
> >> by recent work on a platform that took 16s (sic) to load the mv88e6xxx
> >> module.
> >> 
> >> The first patch gets rid of most of that time by replacing a very long
> >> delay with a tighter poll loop to wait for the busy bit to clear.
> >> 
> >> The second patch shaves off some more time by avoiding redundant
> >> busy-bit-checks, saving 1 out of 4 MDIO operations for every register
> >> read/write in the optimal case.
> >
> > I don't think you should fast-poll for the entire timeout period.
> > Much better to drop to a usleep_range() after the first 2 (or 3)
> > reads fail.
> 
> You could, I suppose. Andrew, do you want a v3?

You have i available, so it would be a simple change. So yes please.

But saying that, it seems like if the switch does not complete within
2 polls, it is likely to be dead and we are about to start a cascade
of failures. We probably don't care about a bit of CPU usage when the
devices purpose in being has just stopped working.

	Andrew