Messages in this thread | | | Date | Thu, 3 Jun 1999 11:51:26 -0700 | From | "David S. Miller" <> | Subject | Re: zero-copy TCP fileserving |
| |
Date: Thu, 3 Jun 1999 13:34:09 -0400 (EDT) From: "Richard B. Johnson" <root@chaos.analogic.com>
There really needs to be a change in TCP/IP RFQs v.s. local area networks now that Ethernet is no longer the BW limiting item.
Something like:
(1) A checksum of zero means don't check the checksum. (2) You can't route a zero-checksum IP packet. If you route it, you must checksum it before routing.
It was an allowed "feature" of UDP for a long time, and promptly more recent RFCs severely frown upon it.
This would allow LANs to operate at higher speeds where a hardware CRC makes sure the data is good anyway, while maintaining compatibility outside the local area. This would also put the total responsibility for the IP checksum with the routers which are designed for it, or slow communications links like PPP, ISDN, and T1, that are so slow the additional overhead is lost in the noise.
No thanks, I and several others have seen hardware fail to verify the CRC correctly. Packet corruption happens on your local network more than you would like to believe.
Even Linus himself saw this in amusing incident while still back in Finland. The LAN's NFS server at the universiry, on the network where he did his kernel work, was a Sun machine which skipped the checksums as you describe for UDP, and when a few weeks after new ethernet card was put into the NFS server, his kernel tarballs would become mysteriously corrupted with single bit errors here and there.
Linus and myself had thought it was a bug in Linux, but later it was shown that the network card in the Sun NFS server would let packets through which had gotten corrupted and the networking stack bypassed verifying the checksum and then boom.
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |