From owner-cvs-all@FreeBSD.ORG Wed Dec 28 15:49:30 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C63C316A41F; Wed, 28 Dec 2005 15:49:30 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AB9E43D5A; Wed, 28 Dec 2005 15:49:30 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id jBSFnTdK021863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2005 10:49:29 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id jBSFnOZf062705; Wed, 28 Dec 2005 10:49:24 -0500 (EST) (envelope-from gallatin) Date: Wed, 28 Dec 2005 10:49:23 -0500 From: Andrew Gallatin To: Gleb Smirnoff Message-ID: <20051228104923.A62638@grasshopper.cs.duke.edu> References: <200512221514.jBMFEgxo020785@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200512221514.jBMFEgxo020785@repoman.freebsd.org>; from glebius@FreeBSD.org on Thu, Dec 22, 2005 at 03:14:42PM +0000 X-Operating-System: FreeBSD 4.9-RELEASE-p1 on an i386 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 15:49:31 -0000 Gleb Smirnoff [glebius@FreeBSD.org] wrote: > - All bge(4) supported hardware, has a bug that produces incorrect checksums > on Ethernet runts. However, in case of a transmitted packet, the latter can > be padded with zeroes, and the checksum would be correct. (Probably chip > includes the pad data into checksum). In case of receive, we just don't > trust checksum data in received runts. > I'm working on a device which has similar "special needs" for runts. When zero-padding outgoing frames, I just allocate ETHER_MIN_NOPAD bytes of zeroed DMA'able memory at driver load time. At run time, I append a descriptor using the zero-padding's DMA address and the appropriate length. That way I don't need to allocate a new mbuf, etc, in the critical path. I assume you did not do it this way just because it would not fit well with the existing bge code.. When recieving runts on this device, the padding may be included in the checksum. So we need to invalidate the checksum like you do for received runts. I think it would be generally better for ip_input to invalidate the checksum if it finds that the packet length as found in m_pkthdr.len is longer than the length it finds in ip header. Having an "incorrect" packet length is probably a good indication the checksum is not correct, and this test would be very cheap as the pkthdr and ip header should be in cache. I know that linux does it this way, and I'm pretty sure MacOSX does also. Drew