Date: Thu, 11 Mar 1999 02:10:01 -0800 (PST) From: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/10535: Very poor ethernet performance with tx driver Message-ID: <199903111010.CAA48108@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/10535; it has been noted by GNATS. From: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU> To: dfr@nlsystems.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG, andreas@FreeBSD.ORG Subject: Re: kern/10535: Very poor ethernet performance with tx driver Date: Thu, 11 Mar 1999 20:01:22 +1000 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). Peter 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?199903111010.CAA48108>