> 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