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] network misbehaviour with gplpv and 2.6.30

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] network misbehaviour with gplpv and 2.6.30
From: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date: Tue, 21 Jul 2009 10:35:34 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Lyon <andrew.lyon@xxxxxxxxx>, Andrew
Delivery-date: Tue, 21 Jul 2009 02:35:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D016DDD27@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D016DDD27@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)
James Harper wrote:
With GPLPV under 2.6.30, GPLPV gets the following from the ring:

ring slot n (first buffer):
 status (length) = 54 bytes
 offset = 0
 flags = NETRXF_extra_info (possibly csum too but not relevant)
ring slot n + 1 (extra info)
 gso.size (mss) = 1460

Because NETRXF_extra_info is not set, that's all I get for that packet.

I assume you mean NETRXF_more_data here? Are you saying that ring slot n has only NETRXF_extra_info and *not* NETRXF_more_data?

In the IP header though, the total length is 1544 (which in itself is a
little strange), but obviously I'm not getting a full packet, just the
ETH+IP+TCP header.

According to Andrew Lyon it works fine in previous versions, so this
problem only arises on 2.6.30. I don't know if netfront on Linux suffers
from a similar problem.

I can't identify any changes that could cause this, but if the problem
is in netback either the frags count isn't being set correctly, or
skb->cb (which appears to be used temporarily to hold nr_frags) is
becoming corrupt (set to 0) somehow, but the window where this could
occur is very small and I can't see where it could happen.

Any suggestions as to where to start looking?

(one nice thing is that I have identified a crash that would occur when
the IP header lied about its length!)

Thanks

James


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


--
===============================
Paul Durrant, Software Engineer

Citrix Systems (R&D) Ltd.
First Floor, Building 101
Cambridge Science Park
Milton Road
Cambridge CB4 0FY
United Kingdom

TEL: x35957 (+44 1223 225957)
===============================

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