From owner-freebsd-hackers Thu Sep 27 9:31:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 7B93137B42A for ; Thu, 27 Sep 2001 09:31:22 -0700 (PDT) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.4/8.11.4) with ESMTP id f8RGVCZ65964; Thu, 27 Sep 2001 12:31:12 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200109271631.f8RGVCZ65964@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Andrew Gallatin Cc: Ronald G Minnich , hackers@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: TCP&IP cksum offload on FreeBSD 4.2 References: <200109271416.f8REGaZ64624@whizzo.transsys.com> <15283.14648.430630.163513@grasshopper.cs.duke.edu> In-reply-to: Your message of "Thu, 27 Sep 2001 10:35:36 EDT." <15283.14648.430630.163513@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Sep 2001 12:31:12 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message