[ovs-dev] [PATCH] ofproto: Do not override internal port MTU.

[Daniele Di Proietto]

Hi Joe,

Thanks for your comments

replies inline




On 31/08/2016 18:48, "Joe Stringer" <joe at ovn.org> wrote:

>On 31 August 2016 at 14:52, Daniele Di Proietto <diproiettod at vmware.com> wrote:
>> Open vSwitch controls the MTU of internal ports and sets it to the
>> minimum of physical ports MTU on the same bridge.
>>
>> Commit 47bf118665a3("ofproto: Always set MTU for new internal ports.")
>> made this more consistent.  Now the MTU is always set, even when the
>> bridge doesn't have any physical ports (e.g. when it has only an
>> internal device and a tunnel).
>>
>> This latest change broke the system testsuite.  Some tests need to
>> lower internal devices MTU because they use tunnels and they want to
>> work with a 1500 bytes underlay.
>>
>> There are other valid usecases where the user/controller needs to
>> configure the internal devices MTU (like mpls push actions, double vlans
>> or any overlay) and there's no way for Open vSwitch to know what the
>> appropriate MTU should be.
>>
>> Since in the general case Open vSwitch is not able to configure a
>> reasonable MTU for internal devices, this commit removes the feature
>> entirely.
>>
>> Now the user/controller is entirely responsible for configuring the MTU
>> of internal ports.  Other hybrid solutions are possible (like not
>> touching the internal interfaces MTU, unless there's a physical device),
>> but they make the current MTU dependent on the previous state of the
>> system (if there was at some point a physical device the MTU would be
>> touched, but it wouldn't be possible to restore it).
>>
>> This change breaks compatibility with previous versions on Open vSwitch.
>>
>> Signed-off-by: Daniele Di Proietto <diproiettod at vmware.com>
>
>So I guess that prior to this patch, there is some sort of contract
>that the MTU of the internal interfaces are entirely managed by OVS,
>and it's set to the minimum of all non-internal devices, then the MTU
>of all other devices is managed by the user/controller. The trouble
>with this is cases where, for instance, the user wants to attach the
>local networking stack to some kind of overlay (tunnel, mpls,
>QinQ,...) and the user either cannot, or does not want to, change the
>underlay MTU to allow encapsulating full 1500B frames. In such a case,
>including the OVS testsuite today (which admittedly can be taught to
>be smarter), the current behaviour prohibits the user from providing
>that more detailed information for the bridge interface. Maybe it
>works in /some/ cases, but OVS will override the MTU if any sort of
>configuration is changed on that bridge.

That's correct

>On the flip side, if a user wants to, for instance, configure OVS to
>provide switching from a physical NIC that supports jumbo frames, then
>today they simply set the MTU of the physical device and OVS takes
>care of the internal device. With this patch, the user/controller
>would be responsible for changing the internal device MTU as well.

Yes

>One thought I have is that it seems like maybe the cases that OVS is
>implicitly figuring out the MTU today are cases where the user already
>has to figure out MTU for another device, so maybe forcing them to
>also configure the internal port's MTU is not a huge burden. Is this
>the case?

I think so

>The other thought I have is that maybe users are more familiar with
>doing "ip link set dev breth0 mtu 1600" rather than using OVSDB to set
>up the MTU. I suspect that even if this is the case, it's simpler if
>OVS doesn't have any implicit logic to reconfigure the bridge device
>MTU rather than potentially override the user configuration. If the
>user wants to do things this way, they can, but it just won't persist.
>If they want it to persist, they can set the configuration in OVSDB.

That's exactly what's happening after this patch.