Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 06 Jun 2001 10:19:15 -0400
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        "Daniel C. Sobral" <dcs@newsguy.com>
Cc:        Giorgos Keramidas <keramidi@otenet.gr>, Bob Willcox <bob@immure.com>, Jesper Skriver <jesper@skriver.dk>, hackers list <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: How to disable software TCP checksumming? 
Message-ID:  <200106061419.f56EJFn82513@whizzo.transsys.com>
In-Reply-To: Your message of "Wed, 06 Jun 2001 06:58:07 -0300." <3B1DFEAF.927E1DC3@newsguy.com> 
References:  <20010529144114.I19771@luke.immure.com> <20010529221107.C49875@skriver.dk> <20010529155212.M19771@luke.immure.com> <20010530045200.A1031@hades.hell.gr> <3B1CACDA.96599BD5@newsguy.com> <200106051422.f55EM4n78505@whizzo.transsys.com> <3B1DFEAF.927E1DC3@newsguy.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> "Louis A. Mamakos" wrote:
> > 
> > >
> > > It seems to me to be kind of moot to check the same value twice, unless
> > > you suspect hardware problems. Aren't you talking about two different
> > > checks over the same data instead of checksum off-loading?
> > 
> > Suspect hardware problem?  Of course you should!  That's why memory
> > systems have parity or ECC, and I/O buses are similarlly protected.  At
> > least on real computers.
> > 
> > The link-level CRC only protects the data as it goes over the link
>       ^^^^^^^^^^
> 
> After reading the rest of his messages, I'm not so sure, but I would
> think he was talking about _transport_ level check sum, and verifying
> that with hardward (NIC) instead of software (IP stack).

If I'm not mistaken the message that started this thread inquired
about adding an option to prevent TCP from doing a checksum, since
the fancy gigabit hardware performed reliable link-level error detection
itself.  I argue that since TCP is an end-to-end transport protocol that
individual error detection on a per-hop basis is not sufficient either
theoretically or practically.  My last message illustrated a number of
cases where the transport of the packet over a link was reliably
done, but the contents of the packet were corrupted by malfunctioning
software or hardware which the end-to-end TCP checksum detected.

I have less of an issue with the endpoints of the TCP connection
offloading checksum computation to the NIC card, though you're
still exposed to a certain class of error, like the PR I referenced.
The problem is what happend to your data in intermediate network
elements (routers, etc.) between the endpoints of the TCP connection.

Louis Mamakos


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?200106061419.f56EJFn82513>