From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 15:01:47 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34D9316A573 for ; Sun, 21 Jan 2007 15:01:47 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 10EF013C467 for ; Sun, 21 Jan 2007 15:01:46 +0000 (UTC) (envelope-from louie@transsys.com) Received: from g5.transsys.com (c-69-141-143-164.hsd1.nj.comcast.net [69.141.143.164]) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 8403F1CC23; Sun, 21 Jan 2007 09:32:11 -0500 (EST) Message-ID: <45B3796A.3020409@transsys.com> Date: Sun, 21 Jan 2007 09:32:10 -0500 From: Louis Mamakos User-Agent: Thunderbird 2.0b1 (Macintosh/20061206) MIME-Version: 1.0 To: "Matthew X. Economou" References: <45AF8586.8080908@IPricot.com><20070118235125.GA80971@xor.obsecurity.org> <45B09856.8080600@IPricot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: tcpdump, rl, sis, fxp and multicast problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 15:01:47 -0000 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