From: Jon Mason <jdmason@us.ibm.com>
Subject: Re: [PATCH] Network Checksum Removal
Date: Sat, 21 May 2005 16:49:38 -0500
Message-ID: <200505211649.39404.jdmason@us.ibm.com>
References: <20050520233015.GA26305@us.ibm.com>
	<7b69de31f49a2b1179da2e52154588a0@cl.cam.ac.uk>
	<3b8c9059967af27880d4144c31f05343@cl.cam.ac.uk>
Reply-To: jdmason@us.ibm.com
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3b8c9059967af27880d4144c31f05343@cl.cam.ac.uk>
Content-Disposition: inline
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Xen-devel@lists.xensource.com

On Saturday 21 May 2005 02:16 pm, Keir Fraser wrote:
> On 21 May 2005, at 15:53, Keir Fraser wrote:
> >> Traffic generated externally, if rx hardware checksum is available and
> >> enabled, then dom0 will notify domU that it is unnecessary to validate
> >> this checksum (providing the checksum is valid) by enabling the csum
> >> bit.  If domU is not notified that it is unnecessary to vaildate the
> >> checksum, then domU will do it.
> >
> > Unfortunately you can't trust the ip_summed flag because, as you point
> > out yourself, the bridge and IP forwarding paths both clobber it to
> > CHECKSUM_NONE. This puts us in a pickle: without hacking in some more
> > info we have no way to know whether the physical interface (eth0, say)
> > summed the packet or not. And, if it did, whether it was a
> > CHECKSUM_UNNECESSARY or a CHECKSUM_HW kind of summing (they differ in
> > how you interpret the result).
> >
> > Your patch as its stands is only correct if eth0 sets
> > ip_summed==CHECKSUM_UNNECESSARY on received packets.

Silly mistake on my part.  Good catch.

> I've checked in a modified version of your patch that hopefully deals
> with propagating checksum information in both directions across a
> virtual bridge or router. I replaced your skb flags with two new ones
> -- proto_csum_blank and proto_csum_valid.
>
> The former indicates that the protocol-level checksum needs filling in.
> This is not a problem for local processing, but the flag is picked up
> before sending to a physical interface and fixed up.
>
> The latter indicates that the proto-level checksum has been validated
> since arrival at localhost (*or* that the packet originated from a domU
> on localhost). This flag survives crossing a bridge/router so we can
> trust it when deciding if checksum validation is required.
>
> I'll push the patch to the bkbits repository just as soon as bkbits
> rematerialises. :-)

I'd be interested in seeing the bits you added.  

> If you have any performance or stress tests that you were using to test
> checksum offloading, it would be great to find out how they perform on
> the checked-in version!

I am happy to give the latest patch some testing (thought I probably won't be 
able Monday).

Thanks,
Jon