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

RE: [Xen-devel] Re: [Xen-users] Release 0.9.10 of GPL PV Drivers for Win

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, Pasi Kärkkäinen <pasik@xxxxxx>
Subject: RE: [Xen-devel] Re: [Xen-users] Release 0.9.10 of GPL PV Drivers for Windows / jumbo frames and xen netback changes
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sun, 22 Jun 2008 21:42:40 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 22 Jun 2008 04:43:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C483F31B.22B79%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D0148FAEC@trantor> <C483F31B.22B79%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjQdtp2GP4D7DxqEd2vHgAX8io7RQD4RMhQAABfBZ4AAEq0sA==
Thread-topic: [Xen-devel] Re: [Xen-users] Release 0.9.10 of GPL PV Drivers for Windows / jumbo frames and xen netback changes
> > Keir: Have you ever considered having the back end publish its MTU to
> the
> > frontend, so the two can be kept in sync?
> 
> Should the backend control the frontend in this respect, or vice versa?
> 

I'd thought about this. For a bridged setup, Dom0 needs to 'control' the MTU 
setting as it needs to match the other devices on the bridge. For a routed 
setup, it might actually make more sense for DomU to control it, although with 
GSO it probably doesn't matter so much what the MTU actually is, and probably 
still makes more sense for Dom0 to be in control.

Some possibilities:

#1. Specify the absolute MTU in the vif config file, which gets written to 
xenstore. DomU would set its MTU to that.

#2. Specify a minimum and maximum MTU value for each vif in the config. For a 
bridged interface they would be set the same. For a routed interface they could 
be something like min=1500, max=9000. DomU would default to the closest MTU to 
1500 that was within the range allowed by Dom0 (for compatibility, or maybe it 
doesn't matter...)

#1 is simple but less flexible. #2 would require the ability to change MTU's on 
the fly, which means some sort of communication channel would need to be set up 
over and above the current 'state' thing. More flexibility but I have to wonder 
if that flexibility is needed...

Are there any situations you can think of where a DomU would be unhappy with 
the MTU it is given, and that making a change to the config file to correct it 
would not be an acceptable solution?

>From my understanding of the linux side of things, the netback driver would 
>just need to write any changes to the MTU to xenstore (if the frontend is not 
>connected), or fail to make the changes (if the fronted is connected).

I'm not sure if a linux kernel driver can control its MTU, although I assume it 
can. On the windows side of things, the kernel driver does have complete 
control over the MTU, although it does involve a remove and re-add of the 
interface to change it.

James


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

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