Re: [Xen-devel] Question about TCP checksum offload in Xen

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

De-html...

------
From: balraj885@xxxxxxxxx [mailto:balraj885@xxxxxxxxx] On Behalf Of Balraj Singh
Sent: 05 December 2013 13:33
To: Richard Mortier
Cc: Paul Durrant; Ian Campbell; xen-devel@xxxxxxxxxxxxxxxxxxxx; Mirage List; 
Anil Madhavapeddy
Subject: Re: [Xen-devel] Question about TCP checksum offload in Xen

Thanks for clarifying Mort.  I did this test: I set up a long lived TCP 
connection from a linux guest to a mirage guest each thru a VIF to the s/w 
bridge.  The various offload settings including checksum offload were the 
default which is ON.  All packets received by Mirage had bad checksums.  Now 
from dom0 I changed the offload settings on the VIFs using ethtool, so the 
checksum offload was OFF.  Now all packets had good checksums.

So to have no packets in the jeopardy of being accepted without their checksum 
verified, I would like to know on each received pkt if the checksum was already 
verified.  Detecting immediately that the setting on the VIF has changed could 
also work, but it would involve throwing away some packets.

Then again, I may have misunderstood something about how the stack should 
interact with the backend.  We do declare (maybe just by staying mute, I think) 
that we can handle packets with no checksums.  But does that mean that we never 
need to do a checksum verification on RX packets?  If so that's the best. 
 Though then I will need to think about what was going on in my test.
-----

And can we avoid top-posting in future, please. It makes it very hard to follow 
threads.

Possibly you ran into the issue because (for some reason) the default is to 
expect a frontend to handle IPv4 TCP/UDP checksum offload. The frontend needs 
to set feature-no-csum-offload to avoid this expectation. I imagine that's what 
you want to do.

Also, the state of the checksum field when being passed a packet for offloading 
will not be zero. It should contain a valid pseudo-header checksum.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel