Re: [Xen-devel] [PATCH] Network Checksum Removal

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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.
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. :-)
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!
 Thanks,
 Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel