netdev
[Top] [All Lists]

Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000
From: Todd Underwood <todd@xxxxxxxxxxxxx>
Date: Thu, 12 Sep 2002 01:28:34 -0600 (MDT)
Cc: "hadi@xxxxxxxxxx" <hadi@xxxxxxxxxx>, "tcw@xxxxxxxxxxxxxxxxxxxx" <tcw@xxxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <20020905.204721.49430679.davem@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
folx,

sorry for the late reply.  catching up on kernel mail.

so all this TSO stuff looks v. v. similar to the IP-only fragmentation 
that patricia gilfeather and i implemented on alteon acenics a couple of 
years ago (see http://www.cs.unm.edu/~maccabe/SSL/frag/FragPaper1/ for a 
general overview).  it's exciting to see someone else take a stab on 
different hardware and approaching some of the tcp-specific issues.

the main different, though, is that general purpose kernel development 
still focussed on the improvements in *sending* speed.  for real high 
performance networking, the improvements are necessary in *receiving* cpu 
utilization, in our estimation. (see our analysis of interrupt overhead 
and the effect on receivers at gigabit speeds--i hope that this has become 
common understanding by now)

i guess i can't disagree with david miller that the improvments in TSO are 
due entirely to header retransmission for sending, but that's only because 
sending wasn't CPU-intensive in the first place.  we were able to get a 
significant reduction in receiver cpu-utilization by reassembling IP 
fragments on the receiver side (sort of a standards-based interrupt 
mitigation strategy that has the benefit of not increasing latency the way 
interrupt coalescing does).

anyway, nice work, 

t.

On Thu, 5 Sep 2002, David S. Miller wrote:

> 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 :-)

-- 
todd underwood, vp & cto
oso grande technologies, inc.
todd@xxxxxxxxxxxxx

"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin


<Prev in Thread] Current Thread [Next in Thread>