WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] tcp/udp checksum and bridging

To: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] tcp/udp checksum and bridging
From: "Steve Prochniak" <sprochniak@xxxxxxxxxxxxxxx>
Date: Mon, 7 Jan 2008 14:33:28 -0500
Delivery-date: Mon, 07 Jan 2008 11:32:36 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D0131A643@trantor>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D0131A643@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchQTq1SohWFYBr6T4mFs52Ka7ynkQBEt/zw
Thread-topic: [Xen-devel] tcp/udp checksum and bridging
The problem is that an operating system may or may not expect the check
summing to be offloaded to the hardware (sounds like it is in this
case), and if the packet doesn't physically leave the system it's not
going to touch the hardware and get that checksum.

There are two solutions:  One is to checksum all incoming packets in the
miniport.  That is of course somewhat an undesirable performance hit.
Plus, Miniports aren't really supposed to know anything about IP and
doing IP checksumming there could be considered a hack.

The other is to respond to the proper NDIS OIDs and tell windows that
checksumming for incoming packets is performed by the hardware.  This
will keep the protocol stack from doing the checksums and dropping all
the packets.  Specifically, handling OID_TCP_TASK_OFFLOAD for
NDIS_TASK_TCP_IP_CHECKSUM will allow you to do that.

Unfortunately OID_TCP_TASK_OFFLOAD will only help you with TCP, as a
windows limitation will not allow you to turn off the checksumming for
UDP and windows will drop all of your internode UDP packets.  Use the
NETRXF_data_validated and NETRXF_csum_blank flags to determine that the
packets are from an internal source, then do a simple test to see if the
packet is UDP.  Once you've determined that, you've got to stamp a
checksum on it yourself before you indicate the packet up to the
protocol stack.

Steve

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
Sent: Sunday, January 06, 2008 5:27 AM
To: xen-devel
Subject: [Xen-devel] tcp/udp checksum and bridging

I have a setup with a Linux PV DomU which is on the same bridge as a
Windows DomU using the PV drivers which Andy and I have been developing.

When a tcp packet originates from anywhere but on the same bridge,
everything is fine, but when the packet originates from a machine on the
same bridge, the checksum is wrong.

I think the problem is that the Linux DomU assumes that something else
will do the checksum of the tcp packet, which is mostly correct unless
the packet is only bridged and not routed...

Any suggestions?

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

<Prev in Thread] Current Thread [Next in Thread>