Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Sep 2001 13:17:11 -0400
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: TCP&IP cksum offload on FreeBSD 4.2 
Message-ID:  <200109271717.f8RHHBZ66485@whizzo.transsys.com>
In-Reply-To: Your message of "Thu, 27 Sep 2001 12:54:55 EDT." <15283.23007.137091.883110@grasshopper.cs.duke.edu> 
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> <15283.23007.137091.883110@grasshopper.cs.duke.edu> 

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.  

And I don't disagree with you, it's wonderful work.

What I guess I'm trying to get across is that like any tool, it ought to
be used properly and in an informed way. For instance, you can mount a
file system async or with soft updates, and each of these choices have
their own trade-offs.

Folks ought to consider the likelyhood of this class of data
corruption, unlikely as it is, and weigh it along with the impact on
your application, and the differences in performance and loading.

louie




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?200109271717.f8RHHBZ66485>