In message <20040716095853.GA15950@colwyn.zhadum.de>,
Matthias Scheler writes:

>On Fri, Jul 16, 2004 at 11:29:18AM +0200, Mipam wrote:

>> Suppose I've got a card which support tcp offloading. It'll be enabled by
>> default, ...
>
>No, it won't, at least not with NetBSD.


Correct (or at least that was the intent); and IMNSO this is
a Good Thing.

There are many ways in which card designers can (and have) gotten
their checksum-offload implementation wrong. There is also the
possibilty that errors will occur after the offloaded checksum -- for
example, due to hardware errors which are "outside" the coverage of
the outboard checksum (e.g., a soft memory failure in internal NIC
buffers, a glitch in an on-chip FIFO, etc).

The Large Vendors selling into the server market seem to've gotten the
systemic bugs out of their offload implementations. OTOH, checksum
offload is now down to ~$20 NICs.  Personally (and after finding such
FIFO bugs, in several low-end NICs), I'd think very, very hard before
enabling checksum offload on such low-end NICs, on any system moving
data I cared about.

Ask yourself, how exhaustive a QA effort is the vendor really likely
to do, at that price?  Will they, for example, make the effort to put
parity on their internal NIC buffers?  Will they force an NMI if they
do detect an error?

OTOH, look at the checksum-offload-bug-workarounds in our
sys/dev/if_bge.c: which I'd probably now trust, in the sense that
undetected errors in, or outside checksum offload (errors that would
be detected by an end-to-end software TCP checksum) are less likely
than errors elsewhere.