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] RE: Linux TCP Checksum offload limitations

To: "Andi Kleen" <andi@xxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Linux TCP Checksum offload limitations
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Tue, 8 Apr 2008 19:37:47 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 08 Apr 2008 02:38:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <87y77opx63.fsf@xxxxxxxxxxxxxxxxx>
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: <AEC6C66638C05B468B556EA548C1A77D013DC2D9@trantor><20080407000238.6e879cf9@xxxxxxxxxxxxxxxxx><AEC6C66638C05B468B556EA548C1A77D013DC314@trantor> <87y77opx63.fsf@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciZUrauAdvKQ2ijQve9U2ucbCKO1wACGa5w
Thread-topic: Linux TCP Checksum offload limitations
> "James Harper" <james.harper@xxxxxxxxxxxxxxxx> writes:
> >
> > 1. Linux definitely requires that the first page in an skb consist
of a
> > complete packet header, and this is a documented requirement but I
> > couldn't find it (eg it's a bug for my Windows PV drivers to give a
> > packet like this to Xen)
> It is true for TX. RX makes some attempts to fix up packets
> in this case (but it's slow), but not TX because it is assumed
> no TX code is stupid enough to do anything like this.

I'm not sure I agree with your declaration of 'stupid'. Windows
presumably gets its share of performance testing so I assume that there
are reasons for doing it this way. I'm guessing that they just reuse the
same page over and over where the Ethernet src and dst address don't
change (always true for a single connection), and use a pool of
pre-setup pages for sending so all they need to do is update the ip
length in the IP header and the seq and ack fields in the TCP header.

Windows has the disadvantage that it has made the assumption that it is
going to be talking to real hardware that can always handle this, not an
emulated hardware device (from Windows PoV) that is a bit more limited
in what it can handle.
> You'll just have to fix it up somewhere in your driver.

Yep. That's what I've done. I'll just have to live with the performance
hit I guess. The fact that I can't tell Windows to please put the whole
packet header on one page is pretty stupid, although the end result in
that case may just be that NDIS does the assembly instead of me.

> Should be enough to do a pskb_may_pull()

My driver is on the Windows side of things, so I'm pretty much stuck
with only giving Linux what it can cope with.

> > 2. As above but it is not documented anywhere (eg it's a bug in the
> > documentation).
> Well like in most complex and fast evolving software documentation
> is not always complete and uptodate.

I would have been happy with a comment in the linux src. That counts as
documentation to me :) But as you said, it's probably a reasonable
assumption that the packet header is completely on one page and just
that this situation has never come up before.

Thanks for clarifying


Xen-devel mailing list