Xen devel - Jan 2008 - checksum offloading not disabled properly in response to ''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.

James

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

> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
http://lists.xensource.com/xen-devel

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

* sprochniak@virtualiron.com [2008-01-11 14:02:57]
> 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.
This should only happen if the frontend declares support for the
scatter-gather feature.

dme.
-- 
David Edmondson, Sun Microsystems, http://www.dme.org

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