tcpdump, rl, sis, fxp and multicast problems
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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