On Wed, Dec 03, 2014 at 10:02:44PM +0000, Thomas Graf 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.
And it's not like tweaking local MTU for one interface will magically fix everything. > That said, I think it is fair to assume that the host knows what role > it plays and can be configured accordingly, i.e. a Netlink API which > exposes the encap overhead so libvirt can max() over it force it onto > the guest or something along those lines. I'd say let's try to at least fix IP traffic properly. -- MST _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
