Date: Fri, 08 Jun 2001 01:38:41 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Fenner <fenner@research.att.com> Cc: louie@transsys.com, freebsd-hackers@FreeBSD.ORG Subject: Re: How to disable software TCP checksumming? Message-ID: <3B208F11.87722148@mindspring.com> References: <20010529144114.I19771@luke.immure.com> <20010529221107.C49875@skriver.dk> <20010529155212.M19771@luke.immure.com> <20010530045200.A1031@hades.hell.gr> <20010529235215.A60177@luke.immure.com> <20010530085155.B24096@Odin.AC.HMC.Edu> <200105310204.f4V248n15260@whizzo.transsys.com> <200106070549.WAA06248@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fenner wrote: > > >The TCP checksum protects more than just the contents of the packet > >on the wire; it's also a (somewhat) weak check on the contents > >of your packet sitting in memory, and as it's going over the bus > >in your computer between memory and peripherals and for other > >end-to-end sorts of issues. > > In fact, Jonathan Stone at Stanford did some measurements of > checksum errors for his thesis, and found that on a given link > in the Stanford residences there were a surprising (small, but > measurable) number of packets with IP header checksum errors > with what appeared to be DMA errors -- e.g. 4 bytes missing > from the middle of the header. When the end to end checksum > is really memory to memory, it can catch errors like this... You need to read the ethernet drivers in /sys/pci/if_*... Specifically, look for m_devget() uses, and the comments about why they are necessary. I will bet you that the 4 byte "holes" that appear to be "DMA errors" are actually driver errors, with drivers sending unaligned packets down to the the DMA engine. Further, if you characterize them, I bet you will see that the majority of them are Linux machines. The problem is that many cards require 4 byte alignment (one of the gigabit cards requires 64 bit alignment) for the DMA engine on the card to function properly. This annoys the piss out of TCP/IP stacks in host machines, which like to cast headers to pointers, and directly access the packet header contents. Naieve driver writers will do a 2 byte align on their assembled TCP/IP packets (causing the IP address to be on a 4 + 2 byte boundary, instead of a 4 byte boundary, and the DMA engine will choke. This all came from IP headers being 14 bytes long, instead of 16. Why card manufacturers can't make their DMA engine use an offset shif buffer is beyond me, but they don't do that, and so unaligned accesses happen. This slows down host processing, best case; worst case, the host is not careful to make the cards happy, and "holes" appear. In fact, it would not surprise me if the person conducting the research had the problem on his system, and the stuff on the network itself was actually all right, since it is generally a receive processing introduced error. 8-). In any case, I still would like an option to turn on the processing in the card, and let me assume that my hardware is monolithic, my card supports checksum offloading, and if I have problems with corruption between my ethernet card and my CPU, I have really, reall bad problems because the CPU and the etherent interface are sitting on the same silicon die which they were fabricated to share. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B208F11.87722148>