[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Re: [Xen-users] Release 0.9.10 of GPL PV Drivers for Windows / jumbo frames and xen netback changes

  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, Pasi Kärkkäinen <pasik@xxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.