Date: Wed, 28 Dec 2005 10:49:23 -0500 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c Message-ID: <20051228104923.A62638@grasshopper.cs.duke.edu> In-Reply-To: <200512221514.jBMFEgxo020785@repoman.freebsd.org>; from glebius@FreeBSD.org on Thu, Dec 22, 2005 at 03:14:42PM %2B0000 References: <200512221514.jBMFEgxo020785@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff [glebius@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051228104923.A62638>