Hi list, I got a wired network problem with a DNATed domU. During a TCP session the domU tries to send juboframes which get lost on the path. I''m using almost stock Debian etch with Xen 3.2.1 from backports. tcpdump says: 17:50:27.595327 IP (tos 0x0, ttl 64, id 48632, offset 0, flags [DF], proto: TCP (6), length: *2948*) 172.31.0.12.80 > 85.239.122.249.1213: . 115841:118737(2896) ack 119 win 181 <nop,nop,timestamp 1187477 3076040081> The TCP handshake has committed a segemt size of 1460. In ifconfig the MTU shows up as 1500. The domU is linked with dom0 by a internal bridge and dom0 acts as gateway. It looks like the frame makes it through the dom0 and gets dropped somewhere on the path, probably the next router. The retransmit is done with a proper size. Some packets later the same behavior occurs again resulting in an overall poor network performance. Is there a way, other than ifconfig, to set the MTU, or force Xen not to send juboframes? Thanks for your thoughts on this issue. Christoph _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > Is there a way, other than ifconfig, to set the MTU, or force Xen not to > send juboframes? >Have you looked here: http://xen.markmail.org/search/?q=jumbo%20frame Cheers, Todd _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 2008-05-12 03:48, Todd Deshane wrote:>> Is there a way, other than ifconfig, to set the MTU, or force Xen not to >> send juboframes? > > Have you looked here: > http://xen.markmail.org/search/?q=jumbo%20frame > > Cheers, > Todd > >Hi Todd, I used google and stumbled across several of these posts. Most of them talk about how to enable jubo frames and whether Xen is capable of it. My problem is quite the opposite. I do not want jumbo frames and have them not fitting through the wire. As far as I have read the MTU is set on the device. So it is done in the domU, plain old 1500 bytes. I checked the vif settings in dom0 and there it reads again 1500 bytes. The path is set to 1500 bytes. I read that the bridge will use the lowest MTU of the enslaved devices (1500 bytes). When capturing with tcpdump, regular Ethernet frames consist of 1514 bytes and some contain *1962* bytes. Those big ones get lost. How to get Xen to stick to the MTU? Kind regards, Christoph _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Cristoph, I had the same problem with some combinations of: hypervisor: xen 3.1.3 or 3.0.4, Dom0: linux 2.6.22 patched with xen 3.1 DomU: linux 2.6.19 patched with xen 3.0.4 or linux 2.6.22 patched with xen 3.1 The problem does not occur with: hypervisor: xen 3.0.4, Dom0&DomU: linux 2.6.19 patched with xen 3.0.4. I think the problem is caused by offloading TCP stream for segmentation from TCP/IP stack to hardware controller (TCP Segmenttion Offload - TSO). Generally this should enhance performance, but when there are no hardware controller (in domU) and instead we have a virtualization software and a virtual ethernet bridge (in dom0) things get complex. DomU virtual NIC driver reports to DomU TCP/IP stack that it is TSO capable. Being so informed, TCP/IP stack does not bother very much in segmenting TCP stream, ignores MTU and passes as large as possible datagrams to NIC driver for proper segmentation. Developers, please correct me if I''m wrong: Xen NIC drivers don''t do segmentation, they pass large datagrams as they are to Dom0 bridge. If the datagram is addressed do dom0, that''s OK. But when the datagram should go outside it cannot fit in MTU of Dom0 NIC, so it is dropped and an ICMP packet is sent to DomU asking to use smaller packets. This causes retransmissions, delays and a very slow transfer. The problem could be solved by entering in domU: /sbin/ethtool -K eth0 tso off This makes DomU TCP/IP stack to segment packets according to MTU and should not prevent from sending jumbo packets if one sets a "jumbo" MTU. Data transfer rate between Dom0 and DomU probably gets slightly degraded. I think, the problem should be addressed somewhere in Dom0 bridge or Xen virtual NIC code/configuration. If someone knows how to do that or better understans the problem, please let me know. Kind regards, -- Bartosz Lis @ Institute of Comp. Science, Technical University of Lodz, Poland bartoszl @ ics.p.lodz.pl _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users