[ovs-dev] Odd gre_sys MTU setting (2.6.x vs 2.8.x)

[Ben Pfaff]

On Fri, Jan 12, 2018 at 01:48:00PM -0500, Eric Garver wrote:
> On Fri, Jan 12, 2018 at 10:18:42AM -0800, Ben Pfaff wrote:
> > On Fri, Jan 12, 2018 at 10:51:11AM -0500, Eric Garver wrote:
> > > On Fri, Jan 12, 2018 at 12:33:23PM +0000, James Page wrote:
> > > > Hi
> > > > 
> > > > We're currently trying to debug an issue we're seeing when using OpenStack
> > > > with OVS 2.8.1 (see [0]).
> > > > 
> > > > When using GRE tunnels, we're seeing broken/slow performance due to what
> > > > appears to be an incorrect MTU setting on the gre_sys device; for previous
> > > > OVS releases (2.6.1 specifically but I think this applies back to 2.5.x as
> > > > well) this device was created with an MTU of 65490; however under 2.8.1 it
> > > > gets created with an MTU of 1472, which when used with GRE networks with
> > > > larger MTU settings causes problems with fragmentation and broken path MTU
> > > > discovery.
> > > > 
> > > > I've tested under Linux 4.4 and 4.13 and see the problem with both kernels.
> > > > 
> > > > Its possible to workaround the issue by setting the MTU on the gre_sys
> > > > device directly, but this change will get reset back to 1472 on a restart
> > > > of openvswitch.
> > > > 
> > > > I know the mtu_request feature was introduced around 2.7.0 - groking the
> > > > code I can't see where the MTU of this device is actually configured...
> > > > 
> > > > Any help much appreciated
> > > > 
> > > > James
> > > > 
> > > > [0] https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1742505
> > > 
> > > Most likely you are seeing this bug:
> > > 
> > >   https://bugzilla.redhat.com/show_bug.cgi?id=1488484
> > > 
> > > It's actually an issue with the kernel GRE driver ignoring IFLA_MTU when
> > > the device is created.
> > 
> > Can OVS work around this by following up its RTM_NEWLINK by an
> > (otherwise redundant) RTM_SETLINK?
> 
> Yes.
> 
> > (And should it do so?)
> 
> I don't see any negative effect other than another round trip to the
> kernel. Worth noting that the other tunnels (vxlan, geneve) are not
> affected.

OK, I sent a patch:
        https://patchwork.ozlabs.org/patch/860192/