That driver despite its *bloated* architecture so well decried on the =
board is on average 10 to 15% faster on NFS tests we ran in our labs and =
in some occasions up to 35%. Tuning of the current driver seems a very =
desirable task to pursue.

Pascal.


-----Original Message-----
From:	Jason Thorpe [mailto:thorpej@wasabisystems.com]
Sent:	Wed 12/17/2003 3:43 PM
To:	Jonathan Stone
Cc:	tls@rek.tjls.com; Pascal Renauld; tech-kern@NetBSD.org
Subject:	Re: A new wm driver=20

On Dec 17, 2003, at 12:18 PM, Jonathan Stone wrote:

> That driver is built on top of a large, OS-independent Intel "library"
> ffor for the Pro/1000 hardware. The line-count for if_em_hw.c includes
> a lot of link-autonegotiaton machinery for OSes that lack (for
> example, NetBSD's MII layer. If you're going to count all the lines of
> code to drive PHYs and handle cable polarity quirks, then you should
> also count corresponding lines from the NetBSD sys/dev/mii.
> (Or just not count the PHY lines, if they're not acutally used.)

The point is that the "em" driver duplicates functionality of existing
code, and has other characteristics that make it undesirable from an
architectural point of view.

Like I said, I'm all for tuning the existing "wm" driver, but an
out-right replacement with something that would take us backwards in
many respects is simply not acceptable.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>