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