Skip site navigation (1)Skip section navigation (2)
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>