rl0 discard oversize

[Chris]

On 28/02/06, Igor Robul <igorr at speechpro.com> wrote:
> On Tue, Feb 28, 2006 at 01:55:56AM -0500, David Scheidt wrote:
> > The RealTek cards supported by the rl(4) driver are trash.  If you want to
> > write a better driver, knock yourself out.  I'm sure Bill Paul won't
> > mind.  Keep in mind that there are other, better performing NICs
> > available for the about same price.
> Most RL8139 cards work fine in our company. Most Windows PCs have these
> cards (slowly replaced by integrated NICs on new motherboards), also
> some FreeBSD-based routers have these NICs.
> _______________________________________________

Likewise fine here, the fact windows outperforms freebsd with realteks
should be enough embarrasement to warrant a rewrite.  A realtek 8139
can easily do full 100mbit with no packet loss but just uses higher
cpu utilisation, also its not always easy to say to a datacentre swap
the card for diff brand.
I like freebsd a lot, but my most worrying thought is their attitude
to low end hardware, alot of 486 and 586 class and low end 686 class
machines fail to boot in 6.x and everytime this is brought up the
hardware is blamed and advised to replace, great if you loaded with
cash.  The comparison with linux is they maintain support for old
hardware.
But I guess telling people their card is trash (when it isnt) is
easier then rewriting a driver, I cant rewrite as I have no knowledge
of coding.
here is a quote from the linux 2.6 driver notes.

"The 8139too driver is based almost entirely on the on the 8139 driver
written by Donald Becker. It has a few operational changes, most of
which are flawed or pointless.
MMIO vs. PIO operation

The 8139 is mapped to both PCI I/O and memory space. Using I/O space
is traditional on x86 architectures, and most drivers are written to
use this mode. However, using the memory space mapping (MMIO) is more
efficient for isolated writes since these are stored in a write buffer
and the processor can continue execution without waiting for the PCI
operation to complete. An added advantage is the processors without
native I/O operations avoid extra address space calculations.

A problem with using this MMIO mode is that the 8139 has different
access alignment restrictions with memory space, and the write buffer
potentially changes the ordering of command writes and subsequent
memory reads.

The 8139too driver attempts to work around the latter problem by doing
a read immediately following a register write. Not only does this
completely eliminate the advantage of having a write buffer, it
doubles the overhead over just using I/O operations!
Added Spin-locks

The 8139too adds spin-locks. However, as with so many of the 2.3
spin-locks, it added them without considering if they were actually
needed. The only code with a potential conflict is when reading and
writing MII registers. But the 8139too driver supports only the 8139,
which has an internal transceiver that is directly accessed by
registers reads. So no spin-lock is needed!
The "rx_size" patch

The 8139too driver adds a patch taken from the BSD driver. This patch
claims to fix a bug in the Rx ring: when copying a packet into RAM,
the length will be 0xfff0. But the BSD "bug" is an artifact of that
driver trying to avoid PCI bus operations by guessing if a packet has
arrived, rather than following the documented method of check the
RxBufEmpty status.

The BSD method is more efficient. Checking the next entry and guessing
can potentially save one or two expensive PCI transactions per Rx
packet. But (as they found out) it is prone to races and failure.

The Linux driver never encounters this problem, but the BSD "bug fix"
was blindly added anyway."

I see they taken something from the bsd drivers but are the other
optimisations mentioned in the bsd driver?

Chris