On 01/06/16 at 01:33pm, David Wragg wrote:
> Prior to 4.3, vxlan vports could transmit vxlan packets of any size,
> constrained only by the ability to transmit the resulting UDP packets.
> 4.3 introduced vxlan netdevs corresponding to vxlan vports. These
> netdevs have an MTU, which limits the size of a packet that can be
> successfully vxlan-encapsulated. The default value for this MTU is
> 1500, which is awkwardly small, and leads to a conspicuous change in
> behaviour for userspace.
>
> This sets the MTU on openvswitch-created vxlan devices to be 65465
> (the maximum IP packet size minus the vxlan-on-IPv6 overhead),
> effectively restoring the behaviour prior to 4.3. Although the
> vxlan_config struct already had a mtu field for this,
> vxlan_dev_configure mostly ignored it; that is also addressed here.
I agree with Jesse that this is fine. The tunnel net_device is a
logical device anyway and the real MTU is not known at this point
until the underlay route has been resolved.
It is really a model we should move away from though. Unless the
endpoints negotiate a proper MTU, the underlay can't possible
cope with this correctly without major performance problems due
to fragmentation.
> @@ -2810,6 +2809,12 @@ static int vxlan_dev_configure(struct net *src_net,
> struct net_device *dev,
> needed_headroom = lowerdev->hard_header_len;
> }
>
> + if (conf->mtu) {
> + err = __vxlan_change_mtu(dev, lowerdev, dst, conf->mtu);
OK, I see the reason for the indirection in the first patch. Never
mind.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
