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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
