[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] network misbehaviour with gplpv and 2.6.30



> 
> 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?

Oops. Yes, that's exactly what I mean.

> 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?).

I've asked for some more debug info but he's in a different timezone to
me and probably isn't awake yet. I'm less and less inclined to think
that this is actually a problem with GPLPV and more a problem with
netback (or a physical network driver) in 2.6.30, but a tcpdump in Dom0,
HVM without GPLPV and maybe in a Linux DomU should tell us more.

Thanks

James

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.