cvs commit: src/sys/dev/bge if_bge.c

[Andrew Gallatin]

Gleb Smirnoff [glebius at FreeBSD.org] wrote:
>   - All bge(4) supported hardware, has a bug that produces incorrect checksums
>     on Ethernet runts. However, in case of a transmitted packet, the latter can
>     be padded with zeroes, and the checksum would be correct. (Probably chip
>     includes the pad data into checksum). In case of receive, we just don't
>     trust checksum data in received runts.
>   

I'm working on a device which has similar "special needs" for runts.
When zero-padding outgoing frames, I just allocate ETHER_MIN_NOPAD
bytes of zeroed DMA'able memory at driver load time.  At run time, I
append a descriptor using the zero-padding's DMA address and the
appropriate length.  That way I don't need to allocate a new mbuf,
etc, in the critical path. I assume you did not do it this way just
because it would not fit well with the existing bge code..

When recieving runts on this device, the padding may be included in
the checksum.  So we need to invalidate the checksum like you do for
received runts.

I think it would be generally better for ip_input to invalidate the
checksum if it finds that the packet length as found in m_pkthdr.len
is longer than the length it finds in ip header.  Having an
"incorrect" packet length is probably a good indication the checksum
is not correct, and this test would be very cheap as the pkthdr and ip
header should be in cache. I know that linux does it this way, and I'm
pretty sure MacOSX does also.

Drew