RE: [Xen-users] Slow TCP performance between Windows Vista and XenPV-on-HVM guest

["Fischer, Anna" <anna.fischer@xxxxxx>]

> Subject: RE: [Xen-users] Slow TCP performance between Windows Vista and
> XenPV-on-HVM guest
> 
> > > Are you capturing packets on the windows machine or on the Dom0?
> >
> > Dom0. Note that the Windows machine doesn't even run Xen or anything,
> it is
> > just some random machine on the network. Only the Linux guest runs on
> Xen.
> 
> Yes, I'd figured that.
> 
> >
> >
> > > If you are using tcpdump on dom0, make sure you use '-s0' so that
> you
> > > capture the entire packup, and possibly '-v' as well. Without
> capturing
> > > the entire packet, tcpdump can't tell you if the checksum is correct
> or
> > > not. Even if the checksum is incorrect on Dom0 it doesn't
> necessarily
> > > tell you that there is a problem though. A bad checksum on received
> > > packets on the windows machine would definitely suggest a problem
> > > though.
> >
> > I capture with Ethereal. I definitely catch all packet. If this was a
> checksum
> > problem, then communication wouldn't work at all. However, SSH and
> other
> > (slower) connections work just fine. The problem is only on bulk data
> transfer
> > using TCP. If the Linux guest was sending a packet with an invalid
> checksum,
> > then the Windows guest would *never* send out the ACK. However, it is
> actually
> > sending out the ACK, but only after the retransmit, to ACK the
> *retransmitted*
> > packet. If this was a checksum problem, then the retransmitted packet
> would
> > also have an invalid checksum and so it would basically never be
> ACKed.
> >
> > I have read about Vista's TCP "auto-tuning" feature, and I wonder if
> something
> > like this might be the problem here that the Xen guest cannot cope
> with?
> >
> 
> It might then be a 'large send' problem. 

Yes, my guess was that it must be something like this.

> That would manifest itself as
> low volume traffic being mostly okay, but as the throughput increased,
> >MTU sized packets would be sent from DomU via Dom0, with the intent
> that the hardware will split them up into <=MTU sized. If those were
> dropped somewhere then the retransmit would happen, and the retransmit
> would typically not use the 'large' packet, so it would probably work.

Is that so? I don't know much about the TCP implementation, but would it 
disable offloading for a retransmit?


> tcpdump should show >1500 byte packets in Dom0 on the vif interface
> belonging to the DomU, and in the DomU if this is happening.

No, I only see < 1500. I capture on the VIF and on the physical device in Dom0.


> Use ethtool in DomU to disable as many offload features as possible and
> see if things improve.

Hardware offload is disabled on the NIC inside the Linux guest, on the VIF in 
Dom0 and also on the NIC in Dom0. All offload features, including checksum 
offload. My guess was also that this must be the problem, as I said before it 
actually works with exactly the same guest running on VMWare. But obviously on 
VMWare it doesn't run the Xen netfront/netback drivers, so my guess was that 
some configuration on there might be the issue. But as I said, switching off 
hardware offload does not make any difference at all. At the moment it does not 
run any HW offloading.

Thanks,
Anna

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