tcpdump, rl, sis, fxp and multicast problems

Peter Jeremy peterjeremy at optushome.com.au
Mon Jan 22 07:43:06 UTC 2007


On Sun, 2007-Jan-21 09:32:10 -0500, Louis Mamakos wrote:
>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.

That's a useful idea.

>  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.

Keep in mind that tcpdump/libpcap in contributed software so making
local changes is frowned upon.

>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.

And given that a 16-bit update is no faster (and typically slower) than
a 32-bit update on all supported architectures, this may even be faster.
Feel free to come up with a patch.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070122/c37b4bf4/attachment.pgp


More information about the freebsd-stable mailing list