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: "Paul Durrant" <paul.durrant@xxxxxxxxxx>
Subject: RE: [Xen-devel] network misbehaviour with gplpv and 2.6.30
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Tue, 21 Jul 2009 21:09:45 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Andrew Lyon <andrew.lyon@xxxxxxxxx>
Delivery-date: Tue, 21 Jul 2009 04:10:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A6594DD.9010808@xxxxxxxxxx>
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> <4A658BE6.4010803@xxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D016DDD99@trantor> <4A6594DD.9010808@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoJ816bpBkMqEhaQR+h3g2lKikfpQAACInQ
Thread-topic: [Xen-devel] network misbehaviour with gplpv and 2.6.30
> James Harper wrote:
> >
> >> Are you saying that ring slot n
> >> has only NETRXF_extra_info and *not* NETRXF_more_data?
> >>
> >
> > Yes. From the debug I have received from Andrew Lyon,
NETRXF_more_data
> > is _never_ set.
> >
> > From what Andrew tells me (and it's not unlikely that I
misunderstood),
> > the packets in question come from a physical machine external to the
> > machine running xen. I can't quite understand how that could be as
they
> > are 'large' packets (>1514 byte total packet length) which should
only
> > be locally originated. Unless he's running with jumbo frames (are
you
> > Andrew?).
> >
> 
> It's not unusual for h/w drivers to support 'LRO', i.e. they
re-assemble
> consecutive in-order TCP segments into a large packet before passing
up
> the stack. I believe that these would manifest themselves as TSOs
coming
> into the transmit side of netback, just as locally originated large
> packets would.
> 

Interesting. My work with the windows NDIS framework said that this must
be very rare as I couldn't find a way to make Windows accept 'large'
packets. GPLPV actually has to break up the packets and checksum them.
Checksum is another thing that Windows is very fussy about. The checksum
on rx has to be correct. There is no 'the data is good, don't worry
about the checksum' flag. Windows seems to check it anyway and drop the
packet if it is incorrect.

James 

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