| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home