Date: Sun, 21 Jan 2007 09:32:10 -0500 From: Louis Mamakos <louie@transsys.com> To: "Matthew X. Economou" <xenophon@irtnog.org> Cc: freebsd-stable@freebsd.org Subject: Re: tcpdump, rl, sis, fxp and multicast problems Message-ID: <45B3796A.3020409@transsys.com> In-Reply-To: <B9638CACBA387E48927BB56B6A1555070D9E59@svr1.irtnog.org> References: <45AF8586.8080908@IPricot.com><20070118235125.GA80971@xor.obsecurity.org> <45B09856.8080600@IPricot.com> <B9638CACBA387E48927BB56B6A1555070D9E59@svr1.irtnog.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew X. Economou wrote: >> not very important but wouldn't it be better to set the checksum >> to 0 instead of some arbitrary (?) and confusing value then ? > > No, as not setting the checksum is a (minor) optimization. Setting that > field to any arbitrary constant means at least one completely > unnecessary CPU instruction per datagram. > > Best wishes, > Matthew > However, since it is a 1's complement checksum, there is a distinguished value (all zero bits) that you could set the checksum field to that wouldn't occur for a normal computed checksum. Since the presence of a checksum is mandatory for TCP, you can use this trick and external software could "know" that it's a distinguished value. This is similar to UDP, where the protocol allows the "no checksum present" case by setting the checksum field to all zero bits. I suspect the overhead isn't the CPU instruction, but the memory reference. If you manipulate the checksum field to the distinguished value at the time the other fields are written, they they'll all get written out to memory when the cache line is flushed. You've already got to initialize the Urgent Pointer field, which is the other 16 bits in the same 32 bit word. If you were really clever, you could make a union to cover both fields and zero both out in the same store instruction. louie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45B3796A.3020409>