On 31 August 2016 at 14:52, Daniele Di Proietto <diproiet...@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 <diproiet...@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.
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?
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@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
