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

RE: [Xen-devel] checksum offloading not disabled properly inresponseto 'feature-no-csum-offload'


  • To: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Steve Prochniak" <sprochniak@xxxxxxxxxxxxxxx>
  • Date: Fri, 11 Jan 2008 09:02:57 -0500
  • Delivery-date: Fri, 11 Jan 2008 06:03:15 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchSuy1241X2K6a2T22bSYUUxHo6RABlrcggAAIRR0A=
  • Thread-topic: [Xen-devel] checksum offloading not disabled properly inresponseto 'feature-no-csum-offload'

Hi James-

Actually you have both of those problems.  Besides the checksum issue
that I described a few days ago, you need to check for NETRXF_more_data
on incoming packets.  When you see that flag, you need to use the data
in the next ring entry to build the current packet.

Steve

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
Sent: Friday, January 11, 2008 8:04 AM
To: James Harper; xen-devel
Subject: RE: [Xen-devel] checksum offloading not disabled properly
inresponseto 'feature-no-csum-offload'

> I think I've finally tracked down the problem I'm having with the PV
> windows drivers.
> 
> Even though I set 'feature-no-csum-offload', and ethtool -k shows that
> it is off, wireshark in the windows domU says that the checksums are
> bad, until I issue the 'ethtool -K vifX.0 tx off' command, and then it
> all comes good. I suspect that Linux is disabling the feature without
> actually disabling the function...
> 
> I haven't done enough testing yet to properly confirm this, but I'm
> reasonably confident that this is the problem.
> 
> Anyone seen anything like this before?
> 
> Ideally, I'd be able to convince Windows to not look at the received
> checksum, but even though I seem to be enabling all the right things
and
> setting all the right flags, Windows won't listen.
> 

I found the _real_ cause of the problem, and it appears to be nothing to
do with checksum offloading, although some of the stuff I tested above
makes me wonder that there is still something I don't understand going
on somewhere.

When packets are created locally (eg on the same linux bridge as the
destination), they can be in several chunks, and the windows PV xennet
driver wasn't looking past the first chunk. This doesn't appear to
happen with non-local packets, which presumably get received off the
wire in a single chunk.

It always helps when you look for the problem in the right place :)

Thanks

James


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

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


 


Rackspace

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