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

[Darrell Ball]

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.



>
> 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
>