WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] Re: domU sending frames larger than MTU

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] Re: domU sending frames larger than MTU
From: "Brian J. Murrell" <brian@xxxxxxxxxxxxxxx>
Date: Tue, 3 Mar 2009 15:01:51 +0000 (UTC)
Delivery-date: Tue, 03 Mar 2009 07:02:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <gogr3h$8di$5@xxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0162CA2F@trantor>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Pan/0.132 (Waxed in Black)
On Tue, 03 Mar 2009 09:56:41 +1100, James Harper wrote:
> 
> It's intended behaviour to send packets that big, but it's a bug that it
> doesn't work for you.

Well, it doesn't exactly not work.  IP does what it's supposed to and the 
Dom0 (which is 192.168.0.254 on the br0 that is bridged with the DomU 
"private" net from the packet trace in my previous posting) sends the 
icmp "needs frag" to the DomU and then the DomU resends the 4044 bytes 
chopped up into more "ethernet friendly" sized packets, which the Dom0 
put out onto the ethernet.

> The idea is that DomU sends big packets, and the
> hardware adapter splits them up into MTU sized packets.

You know I was very sceptical of this until I did some googling given 
then "tso" ethtool option you pointed out below, which led me to http://
en.wikipedia.org/wiki/Large_segment_offload.  TBH, I had not heard of 
this before.  Interesting that they are building that kind of 
intelligence into NICs these days.

So the theory might be then that the physical NIC in the Dom0 doesn't 
support this offloading and so the IP stack in the Dom0 has no choice but 
to ask the sender to fragment the packets itself.  Looking at it with 
ethtool, this is what the NIC in the Dom0 reports:

Dom0# ethtool -k eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off

Maybe I just need to enable it.

# ethtool -K eth0 tso on
Cannot set device tcp segmentation offload settings: Operation not 
supported

So perhaps this NIC (Broadcom Corporation BCM4401 100Base-T) doesn't have 
TCP offload.

> What is your DomU?

Linux.

> If it's linux (pv or hvm) you can use ethtool to disable the large send
> offload, eg ethtool -K eth0 tso off

Next time I have those domUs up, perhaps I will give that a try.  That 
ethtool command is on the DomU, right?  So it's fiddling with the virtual 
ethernet port, yes?

Cheers,
b.



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

<Prev in Thread] Current Thread [Next in Thread>