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

[Daniele Di Proietto]

Hi Darrel,

thanks for your comments

Replies inline




On 31/08/2016 21:02, "Darrell Ball" <dlu998 at gmail.com> wrote:

>
>
>On Wed, Aug 31, 2016 at 6:48 PM, 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.
>
>
>
>
>ip and mpls tunnels that traverse multiple transport nodes have another issue;
>PMTU could help in many cases, but not all.
>Even just local to the source transport node, figuring out the path taken, which
>can change requires added infra to get it right and optimal in an automatic, general
>and timely manner. I am not sure the added complexity is worth it,
>in the case of ovs.
>
>
>If OVS is in the business of controlling non-internal interface MTUs, as it
>is with the addition of the mtu_request column, then it seems useful to be able
>to also "manually" control the mtu of internal interfaces, when needed, as this
>patch proposes.
>
>
> 
>
>
>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.
>
>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?
>
>
>
>
>Dealing with internal interface MTU configuration seems like some added
>burden, including users understanding the internal interfaces relationships.
>I thought that the main benefit of the present auto-configuration
>of MTU for internal interfaces is simplicity.
>
>
>I am not sure completely removing the default behavior of auto-configuring
>internal interface MTUs to the minimum of non-internal interfaces is the
>way to go, even though it is not optimal in all cases; it seems like there
>might be some simplicity benefit for some users.
>Being able to override this default behavior, as proposed with this patch
>seems useful.

This patch completely removes the default behavior.  I think it's the cleanest
solution, even though I'm worried about compatibility.


>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.
>_______________________________________________
>dev mailing list
>dev at openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev
>
>
>
>
>
>
>
>