Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 5 Sep 2002 23:49:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 5 Sep 2002 23:49:52 -0400 Received: from pizda.ninka.net ([216.101.162.242]:64641 "EHLO pizda.ninka.net") by vger.kernel.org with ESMTP id ; Thu, 5 Sep 2002 23:49:52 -0400 Date: Thu, 05 Sep 2002 20:47:21 -0700 (PDT) Message-Id: <20020905.204721.49430679.davem@redhat.com> To: hadi@cyberus.ca Cc: tcw@tempest.prismnet.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000 From: "David S. Miller" In-Reply-To: References: <200209051830.g85IUMdH096254@tempest.prismnet.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 977 Lines: 23 From: jamal Date: Thu, 5 Sep 2002 16:59:47 -0400 (EDT) I would think shoving the data down the NIC and avoid the fragmentation shouldnt give you that much significant CPU savings. It's the DMA bandwidth saved, most of the specweb runs on x86 hardware is limited by the DMA throughput of the PCI host controller. In particular some controllers are limited to smaller DMA bursts to work around hardware bugs. Ie. the headers that don't need to go across the bus are the critical resource saved by TSO. I think I've said this a million times, perhaps the next person who tries to figure out where the gains come from can just reply with a pointer to a URL of this email I'm typing right now :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/