[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: 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. 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. Yes, a tcpdump of what's being passed into netback in dom0 should tell us what's happening. Paul -- =============================== 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |