Subject: Re: freebsd em driver
To: None <itojun@iijlab.net>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-net
Date: 06/17/2002 11:09:30
In message <20020617082855.3DF9B4B24@coconut.itojun.org>,
itojun@iijlab.net writes:
> it seems that there's freebsd driver for Intel PRO/1000 cards,
> contributed from Intel. it supports some of the recent cards
> that if_wm.c does not support.
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/
>
> are there anyone working on getting diffs back into if_wm.c?
You mean support the 82540EM/82545EM/82546EB (dual-port?) support?
That'd be great, but since you ask...
One should, perhaps, consider ditching if_wm.c altogether; and
instead, gluing the necessary NetBSD support (nbsd-clean
mbuf-dma-mapping code, suport for the next-to-latest chips, and
Jason's 82544 support) into the framework of FreeBSD gx driver.
Why suggest this? I foudn the the throughput of the wm driver is on
par (or worse!) than matt jacob's wx driver. The gx driver does
significantly better (on FreeBSD) than either. In the cases I've
examined closely, the gx driver is (ihho) better-written (given the
looser constraints of FreeBSD) than is the wm driver.
Alternatively one could graft most of the `brains' of the gx driver
(whatever-it-is in interrupt processing, setup, etc that makes it go
faster) into the existing wm framework. However one wants to look at
it, the resulting code would be a hybrid of the two.
Example: attempt to debug the (several) problems with 82543(?)
support. Compare and contrast the code in if_gx for the same chip
revisions. Decide for yourself which is the cleaner code.
(I ended up glomming in the FreeBSD code.)