Re: [PATCH] Network Checksum Removal

[Bin Ren <bin.ren@gmail.com>]

Machines spec:

External server:
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 08
Memory: 1024M DDR400 CAS 3
NIC: 1Gb/s Intel Pro/1000 MT Desktop

Xen machine:
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: AMD Sempron(tm) 2200+ stepping 01
Memory: 1024M DDR400 CAS 3
NIC: 1Gb/s Intel Pro/1000 MT Desktop

The highest number I'm seeing here is 760Mbps running native linux on
the Xen machine. dom0->external server gets 650Mbps. dom1->external
server is definitely low using the default BVT. I've recently
implemented a Xen scheduler based on Earliest Eligible Virtual
Deadline First, which gives 610Mbps for dom1->external, ~50%
improvement over BVT. I'm still figuring out why.

On 5/23/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > Overall though these are the kind of results I would expect.
> > Linux usually does csumming at the same time as it has to do
> > a copy anyway, and it ends up being limited by
> > memory/L2-cache bandwidth, not the extra computation. But the
> > offload extensions haven't cost much to implement and there
> > are probably cases where it helps a little.
> >
> > Maybe I'm being pessimistic though: Can you reproduce the
> > rather more impressive speedups that you previously saw, Jon?
> 
> We should be getting some benefit on the receive path, where the
> checksum is normally forced to happen independent of a copy. Having this
> offloaded to hardware should produce some measureable gain.
> 
> Bin: The numbers you're seeing are terrible anyway. You should be seeing
> 890Mb/s for external traffic. What kind of machine is this on?
> 
> Ian
>