Date: Thu, 27 Sep 2001 12:54:55 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: hackers@FreeBSD.ORG Subject: Re: TCP&IP cksum offload on FreeBSD 4.2 Message-ID: <15283.23007.137091.883110@grasshopper.cs.duke.edu> In-Reply-To: <200109271631.f8RGVCZ65964@whizzo.transsys.com> References: <Pine.LNX.4.33.0109270728220.26552-100000@snaresland.acl.lanl.gov> <200109271416.f8REGaZ64624@whizzo.transsys.com> <15283.14648.430630.163513@grasshopper.cs.duke.edu> <200109271631.f8RGVCZ65964@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Louis A. Mamakos writes: > 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. What happens if that same i/o transfer splatted over the buffer waiting in user space prior to the copyin, or sitting in the socket buffer prior to a software checksum being done? Software checksums are not quite the panacea you make them out to be. And they're very expensive. Geez. All I wanted to do was pat Jonathan on the back for coming up with what is apparently the most flexible and well though out mechanism out there. These issues have been argued to death; I don't feel like arguing with you. I'm satisified that I'm not going to convince you & you're not going to convince me. Drew 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?15283.23007.137091.883110>