From owner-cvs-src@FreeBSD.ORG Tue Jun 28 16:15:03 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6075116A41C; Tue, 28 Jun 2005 16:15:03 +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 196AD43D53; Tue, 28 Jun 2005 16:15:00 +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 j5SGExOf014808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2005 12:14:59 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j5SGEsma075622; Tue, 28 Jun 2005 12:14:54 -0400 (EDT) (envelope-from gallatin) Date: Tue, 28 Jun 2005 12:14:54 -0400 From: Andrew Gallatin To: Luigi Rizzo Message-ID: <20050628121454.A75589@grasshopper.cs.duke.edu> References: <200506270736.j5R7a3OZ036531@repoman.freebsd.org> <20050627152155.GF93072@ip.net.ua> <20050627083101.B56456@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050627083101.B56456@xorpc.icir.org>; from rizzo@icir.org on Mon, Jun 27, 2005 at 08:31:01AM -0700 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/netinet/libalias alias_ftp.c alias_irc.c alias_local.h alias_proxy.c alias_skinny.c alias_smedia.c alias_util.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 16:15:03 -0000 Luigi Rizzo [rizzo@icir.org] wrote: > On Mon, Jun 27, 2005 at 06:21:55PM +0300, Ruslan Ermilov wrote: > ... > > Why can't we just say that checksum offloading is incompatible > > with NAT (like with many other things), and do the software > > checksum calculations in libalias? > > actually the more i see it the more i think checksum offloading > is a disgrace rather than a performance boost. > > it needs a lot of special cases throughout the protocol stack > to be supported properly, which constitutes extra overhead > with low-end hardware which does not support the offloading; > > it does not pay on small packets such as acks where you have > to touch the whole packet anyways; There are definately tradeoffs, but let's not throw the baby out with the bathwater. In terms of IP header checksum offload, I could not find any case where doing IP header checksums in our (relatively slow) 333MHz network proccessor was faster than doing them on the 10x faster host CPU. This is mainly because the host has to touch the header anyway, so its already going to take the cache misses to access it. So our driver/firmware does not support IP header checksum offload, but it does support TCP and UDP checksum offload. Where checksum offload really buys you something is when you're on an endstation, and you're not touching the data at all (sendfile sends) or when you're not touching the data for a long time (recv into a socket buffer where the app does not check it for a while). On our 4Gb/sec adapters, checksum offloading is the difference between being able to send via sendfile at 3.95 Gb/sec vs 3.2Gb/sec with a higher CPU utilization. And this is on an SMP P4 where the sfbuf code does some expensive VM magic. The difference would be more pronounced on an opteron. With 10GbE just around the corner, avoiding data touches is more important than ever. Drew