Date: Thu, 11 Mar 1999 02:24:36 -0800 From: David Greenman <dg@root.com> To: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/10535: Very poor ethernet performance with tx driver Message-ID: <199903111024.CAA07672@implode.root.com> In-Reply-To: Your message of "Thu, 11 Mar 1999 02:10:01 PST." <199903111010.CAA48108@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Doug Rabson <dfr@nlsystems.com> wrote: > >The fix looks correct to me but as DG noted when the last change was made > >to this driver, it should be using DELAY to avoid future problems with > >processor speeds. > > I think that's a separate issue. The current code is incorrect because > references to H/W registers aren't marked volatile - and are therefore > likely to be optimised away. Andreas' change made the problem show > up because of the extra delay. I'm surprised that the only symptom > was poor performance. > > >If these are changed to call DELAY(1) in the loop, I think the original > >patch to increase the loop in epic_init_phy wouldn't be needed either. > > I agree that delays should be done using DELAY(). The problem is that > DELAY() isn't really ideal for the situation in > epic_{read,write}_phy_register: The code is polling a `ready' bit and > the limit just makes sure that things don't lock up. (I'm sure > there's similar code in lots of device drivers). It would be nice if > the kernel supported something equivalent to setitimer(2)/SIGALRM for > this purpose. > > Based on a quick look at DELAY() (and without knowing the range of > expected delay's), I suspect that changing the code to do DELAY(1) on > each loop would worsen the performance - particularly on slow > processors where the overheads in DELAY() are significant (>1us). > (Once the bit becomes ready in the PHY, it will typically be (1usec + > DELAY() overhead)/2 before the state change is seen - compared with > ~10 clocks for the current code). The real question in my mind is why does the driver frob with the PHY in a critical path? That's guaranteed to cause the performance to suck, no matter what you do with the for-loops. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903111024.CAA07672>