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


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,
> > is _never_ set.
> >
> > From what Andrew tells me (and it's not unlikely that I
> > 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
> > are 'large' packets (>1514 byte total packet length) which should
> > be locally originated. Unless he's running with jumbo frames (are
> > Andrew?).
> >
> It's not unusual for h/w drivers to support 'LRO', i.e. they
> consecutive in-order TCP segments into a large packet before passing
> the stack. I believe that these would manifest themselves as TSOs
> 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.


Xen-devel mailing list