> > Louis A. Mamakos writes: > > The other type of failure you might not catch are software errors; that > > is, where a packet is produced by the network stack and then is > > subsequently stomped on by a random store from some other code. Or > > a mis-programmed I/O card with scatter/gather capability doesn't pick > > up what was intended, etc. The Internet checksum is useful for > > detecting this class of error. > > > > No, you're missing the point almost entirely. The checksum is not > skipped. It is calculated by the DMA engine based on the data that's > transferred across the I/O bus on the receiver (and / or the sender). > If the data is incorrect as seen by the receiving nic, the checksum > will be wrong and the packet will be dropped.
I was referring to the case on the transmit side where the wrong data get's gathered up by the DMA engine because of software related errors. You get a valid checksum, but for the wrong data. You might have the wrong data because a drive screwed up setting the DMA descriptors, or some other I/O transfer splatted over the buffer waiting in a transmit queue. > If the packet lands in the wrong place, you have much worse problems. Sure you do; a software checksum at least gives you an opportunity to detect these failures. While these are improbable failures, I know that I've experienced the class I described in my years of hacking on network platforms, and Ron has experienced the one he described. These are not impossible occurances; it's a matter of weighing the additional cost of the software checksum vs. the likelyhood (and cost/impact) of undetected corruption of the data. If you're running IPSEC or SSL up above all this, there's another mechanism to detect these types of failures. I just think back 10 or 15 years at the impact of Sun's decision to not compute UDP checksums on their NFS traffic, because the network adapter had a much stronger Ethernet CRC. It was a trade-off not worth making even then, with CPUs in the single-digit MIPS performance. We ought to at least consider the previous experience. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
