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>