[ovs-dev] [PATCH net v2 2/3] geneve: Relax MTU constraints

[Jesse Gross]

On Wed, Feb 10, 2016 at 3:21 PM, Tom Herbert <tom at herbertland.com> wrote:
> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross <jesse at kernel.org> wrote:
>> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg <david at weave.works> wrote:
>>> Tom Herbert <tom at herbertland.com> writes:
>>>> The correct thing to do is determine the maximum amount of
>>>> encapsulation overhead that can ever be set in a packet and use for
>>>> setting the MTU. For instance, when RCO is enable in GUE, the size of
>>>> the option is included in tunnel->encap_hlen even though it will not
>>>> be used in all packets (via ip_tunnel_change_mtu). If there is no way
>>>> to determine a maximum overhead a priori from configuration, then
>>>> maximum overhead could be assumed to be maximum possible encapsulation
>>>> header size which for Geneve is 132 bytes IIRC.
>>>
>>> Ok, I'll come up with a patch to address this.
>>
>> I don't think that this really applies in this situation. The concerns
>> here relate to what the MTU is actually set to but this patch affects
>> the range of MTUs allowed to be set by the user. I don't see a reason
>> to disallow the user from setting a precise value if they know what it
>> should be.
>>
> Right, but if the user sets a bad value and packets are silently
> dropped on the floor then that seems like a bad result that could have
> easily been prevented.

Sure, we might as well prevent the extreme edge cases that can never
be valid. In the case of Geneve though, this would be the minimum
header size, not the maximum, since it's possible that the user
actually knows how big the options are that they want to use.

But as I said, the practical impact is low because IP_MAX_MTU is so
much larger than the MTU of real devices. There will always be many
values that the MTU can be set to that result in dropped packets. This
is true of all tunnel types.