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] [day] [month] [year] [list]
Message-ID: <29f644f8322e4d79ad861a8347ddea0d@AcuMS.aculab.com>
Date:   Fri, 28 Jan 2022 16:31:32 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andrew Lunn' <andrew@...n.ch>,
        Tobias Waldekranz <tobias@...dekranz.com>
CC:     "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

From: Andrew Lunn
> Sent: 28 January 2022 16:11
> 
> 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.

But you don't want to destroy everything else on the system while
all the requests are failing either.
(I've also just seen v3)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ