[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

Thanks,

Balraj


On Thu, Dec 5, 2013 at 12:55 PM, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:

On 5 Dec 2013, at 12:47, Paul Durrant wrote:

...
>>>> On Tue, Dec 03, 2013 at 01:00:23PM +0000, Balraj Singh wrote:
>>>>
...
>>>>> It should ideally be for every packet since chksum
>> offload
>>>>> can be turned off and on on the VIF and existing tcp connections should
>>>>> continue.  If not every packet, I need to get a notification or efficiently
>>>>> detect right away that the setting is changed on the VIF.

...

> earlier today, i wrote:
>
>> i think balraj's question arises because the status of checksum offload can
>> change mid-tcp-flow. how does he know whether it's on or off for a given
>> packet?
>
> Why do you assert that it can change mid-flow? The configuration is decided at ring connect time. Nothing should change after that. If, at that time, the frontend declares it can handle packets with no checksum then clearly it may get some packets that do have checksum as well as ones that don't, depending on where they originated.

i didn't mean to :) i was just trying to point out to ian the reason for balraj's question -- i'll leave it to balraj from here...

--
Cheers,

R.




This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.






 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.