On Wed, Dec 3, 2014 at 2:02 PM, Thomas Graf <tg...@suug.ch> wrote: > On 12/03/14 at 11:38am, Jesse Gross wrote: >> On Wed, Dec 3, 2014 at 10:38 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > Both approaches seem strange. You are sending 1 packet an hour to >> > some destination behind 100 tunnels. Why would you want to >> > cut down your MTU for all packets? On the other hand, >> > doubling the amount of packets because your MTU is off >> > by a couple of bytes will hurt performance significantly. >> > >> > Still, if you want to cut down the MTU within guest, >> > that's only an ifconfig away. >> > Most people would not want to bother, I think it's a good >> > idea to make PMTU work properly for them. >> >> I care about correctness first, which means that an Ethernet link >> being exposed to the guest should behave like Ethernet. So, yes, IPX >> should work if somebody chooses to do that. >> >> Your comments are about performance optimization. That's fine but >> without a correct base to start from it seems like putting the cart >> before the horse and is hard to reason about. > > I agree with Jesse in particular about correctnes but Michael has a > point (which I thing nobod objects to) which is that it may not always > make sense to force the MTU onto the guest. It clearly makes sense for > the edge server connected to an overlay but it may not be ideal if > WAN traffic is VXLAN encapped and local DC traffic is put onto a VLAN.
The question is whether you would do this in a single L2 segment. It's possible, of course, but probably not a great idea and I'm not sure that it's really worth optimizing for. We do have one existing example of this type of MTU reduction - the bridge device when you attach multiple devices with varying MTUs (including a VXLAN device). In that case, the bridge device is effectively acting as a connection point, similar to virtio in a VM. My proposal would be something like this: * For L2, reduce the VM MTU to the lowest common denominator on the segment. * For L3, use path MTU discovery or fragment inner packet (i.e. normal routing behavior). * As a last resort (such as if using an old version of virtio in the guest), fragment the tunnel packet. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
