On Wed, Jan 6, 2016 at 3:25 PM, David Wragg <david@weave.works> wrote: > David Miller <da...@davemloft.net> writes: >>> Prior to 4.3, openvswitch 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. >>> >>> These two patches set the MTU on openvswitch-crated vxlan devices to >>> be 65465 (the maximum IP packet size minus the vxlan-on-IPv6 >>> overhead), effectively restoring the behaviour prior to 4.3. In order >>> to accomplish this, the first patch removes the MTU constraint of 1500 >>> for vxlan netdevs without an underlying device. >> >> Is this really the right thing to do? > > I'm certainly open to suggestions of better ways to solve the problem.
One option is to simply set the MTU on the device from userspace. The reality is that the code you're modifying is compatibility code. Maybe we should make this change to preserve the old behavior for old callers (although, again, it should not be just for VXLAN). But no new features or tunnel types will be supported in this manner. New or updated userspace programs should work by simply creating and adding tunnel devices to OVS. That won't go through this path at all so you're going to need to find another approach in the near future in any case. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
