From owner-freebsd-hackers Sat Jun 9 14:25:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 88AB737B401 for ; Sat, 9 Jun 2001 14:25:23 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f59LZW701229; Sat, 9 Jun 2001 14:35:33 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200106092135.f59LZW701229@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: Bsdguru@aol.com, freebsd-hackers@FreeBSD.ORG Subject: Re: How to disable software TCP checksumming? In-reply-to: Your message of "Sat, 09 Jun 2001 10:22:06 PDT." <3B225B3E.5C3D0FC0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2001 14:35:32 -0700 From: Mike Smith 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 > Tell me: at what point are you willing to trust the data? > > Is "the card plus the motherboard" my machine, or is it > just "the motherboard"? > > The cards support offloading the checksum to hardware; > you are saying that it is never reasonable to do this. No, that's not what's being said. > Fine. That basically means that we need to checksum the > contents of memory once they have been loaded into the > L2 cache, to make sure they arrived safely from memory. That's why you have an ECC memory datapath. > Wait... now we need to checksum them in L1 cache, once > they have arrived from L2. And that's why you run ECC on the L2 cache as well. > Wait... now we need to checksum them in the pipeline, as > they have arrived from our untrustworthy L1 cache... And... yes, you got it. Some people will even ECC the L1 cache. > At some point you have to draw the boundary between the > "inside" and the "outside". I am happy to draw this > boundary at the etherenet cable; why are you insisting > that I draw it at the PCI bus instead? Well, if PCI parity worked, you could trust the PCI bus more, but the bottom line is simply that you can't trust *anything*, and the more that you do trust, the more you expose yourself to risk. > Does your requirement apply to devices integrated on the > motherboard, or is your concern solely with the mechanical > PCI connectors between the boards and the motherboard? PCI is typically implemented as a no-parity bus. Anything from poor drive to coupled noise to a simple alpha-decay error in a pipeline FIFO somewhere will cause PCI bus data corruption. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message