>While i love the 21164A, it's much more useful as a CPU than a network
>interface.  The 21140A, on the other hand...  8-)

Doh... yes, that's what  I meant. 

The original and early steppings of the 21140A restricted DMA to fall
on 32-bit-aligned boundaries. Since Ethernet headers are 14 bytes,
that means the network-level packet falls on an odd 16-bit boundary.
In a BSD networking stack, that necessitates a copy of at least the
IP/TCP/UDP header, so that the IP header fields are aligned on 32-bit
boundaries.    (This is one area where the Intel EtherExpress Pro
wins out over the alternatives).

I beleive a newer stepping of the 21140 removes this constraint.  _If_
the kernel is smart enough to avoid `m_pullup()' on contiguous,
properly-aligned packets, then having the IP header DMAed into memory
on an appropriate boundary is a win. (It eliminates allocating an mbuf
fragment and copying the data into it).

Last time I instrumented the ip_cksum code, NetBSD was *not* smart
enough to avoid this, so the point may be moot.

The programmed-IO 3Com cards effectively require an interrupt and an
explicit copy for every packet. This is supposedly a win for a
dedicated server with a `squashed' IPX network stack.  The numbers I
have suggest it's at best marginal, and perhaps worse than DMA, for
100Mbit speeds and a BSD networking stack.

Thinking about it more,  the packet buffers on the cheaper (ISA)
3Com cards are so small that the CPU interrupt load may be higher
than you'd like.   

Perhaps a PCnet-PCI card might be worth considering too.  They're
basically a LANCE chip and a PCI interface integrated onto one chip,
they're relatively cheap, the LANCE is just fine at 10Mbits/sec,
and NetBSD-current appears to have a driver.

Tho' I suspect a _real_ i386 is limited to ISA, in which case a
_working_ ne2000 clone (i.e., one that works with the if_ed driver :-))
might be the best buy.