Date: Mon, 22 Jan 2007 18:43:04 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Louis Mamakos <louie@transsys.com> Cc: freebsd-stable@freebsd.org Subject: Re: tcpdump, rl, sis, fxp and multicast problems Message-ID: <20070122074304.GB837@turion.vk2pj.dyndns.org> In-Reply-To: <45B3796A.3020409@transsys.com> References: <45B09856.8080600@IPricot.com> <B9638CACBA387E48927BB56B6A1555070D9E59@svr1.irtnog.org> <45B3796A.3020409@transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtGsI/opHv/APuIcRAoLzAJ9Hzzvr0Q9sVbUwjoEsS4+dkCpQBACfZ3bP E4UsV7Zx1cNVTOTbhRkLObU= =jhIk -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070122074304.GB837>