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/
Home Products Support Community News


[Xen-devel] Linux TCP Checksum offload limitations

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Linux TCP Checksum offload limitations
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Fri, 4 Apr 2008 22:04:53 +1100
Delivery-date: Fri, 04 Apr 2008 04:05:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciWQ7V8Bs7yhl7zT9mECnz6ZKd7Og==
Thread-topic: Linux TCP Checksum offload limitations
Some version of Windows appear to give the network adapter driver a
packet broken up into fairly small pieces, eg
Page 0: 14 bytes of Ethernet Header
Page 1: 20 bytes of IP Header
Page 2: 20 bytes of TCP Header
Page 3: 1460 bytes of TCP Data

When this happens, Linux appears to not pass the packets beyond the
vifX.Y interface - a tcpdump on (say) vif455.0 shows packets but a
tcpdump on eth0 does not show all the packets - packets with a bad
checksum don't make it that far.
Our best guess is that the Linux checksum offload code can't cope with
the way Windows is fragmenting the packets, but maybe Xen is somehow
involved in this...

Can someone please confirm that this is a limitation of Linux and/or



Xen-devel mailing list