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 21:01:13 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 08 Apr 2008 04:01:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080408105238.GM16647@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>
References: <87y77opx63.fsf@xxxxxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D013DC362@trantor> <20080408105238.GM16647@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciZZiQTFsqjr4gmQwS9A6lIpWjUZQAAMXsA
Thread-topic: Linux TCP Checksum offload limitations
> > I'm not sure I agree with your declaration of 'stupid'. Windows
> stupid in the context of linux networking. Other systems have other
> tradeoffs.


> > presumably gets its share of performance testing so I assume that
> > are reasons for doing it this way. I'm guessing that they just reuse
> > 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
> >
> That would sound pretty dumb if true because ethernet headers are very
> very
> cheap to set up. If if you consider reusing IOMMU mappings (which
> doesn't support anyways afaik) it probably wouldn't be a good idea.

If you are sending hundreds of thousands of packets per second then
reusing the same page over and over might give you some benefit. No
setup is better than very cheap setup. But...

> > Windows has the disadvantage that it has made the assumption that it
> > 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
> > in what it can handle.
> Even real hardware goes slower when it has to do more scatter-gather

Yes. I hadn't thought of that. I guess it depends on if "allocating a
page, looking up and copying the src and dst mac address" is cheaper
than "get the same page we used last time and putting it on the sg
list". With the latter, we are still sending actual data so there is
still a page to allocate for that anyway, and for the rest of the
headers... As I said, Microsoft as a whole appears to act pretty stupid
at times, but I'm sure their coders know how to do performance analysis
on driver behaviour and figuring out which gives better performance.

> > > 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
> > hit I guess. The fact that I can't tell Windows to please put the
> If you code it right the performance hit should be rather small. You
> just have to copy the header, not everything.

Yep. I allocate a new page (well... just get it off my freelist) then
just loop around and keep appending data until I have a full header.

> > > 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.
> I meant on the Xen frontend side.

My windows driver is the xen frontend. It is to Windows what netfront is
to Linux. Linux obviously doesn't have this problem on it's frontend :)


Xen-devel mailing list

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