On Thu, Sep 1, 2016 at 10:17 AM, Daniele Di Proietto
<diproiet...@vmware.com> wrote:
> Let me try to sum up the problem further
>
> 1) Behavior on master, before commit 47bf118665a3("ofproto: Always set MTU
> for new internal ports."):
>
> a) When an internal interface is added, or its MTU has changed we only
> change its MTU if it is bigger than the bridge minimum
> b) When a non internal, non tunnel port is added, we reconfigure every
> internal interface to match exactly the bridge minimum, no matter what
> c) If the bridge doesn't have physical ports (only tunnels and
> internals), we consider the minimum mtu to be invalid and we don't change the
> internal interfaces mtu
>
> I felt that there was an inconsistency between 1a and 1b. I thought 1c was
> not very clean, because the current configuration depends on the previous
> state (if there were physical ports at some point, we would lower the
> internal interfaces mtu, but we couldn't restore it when they were removed)
>
> 2) Behavior on master after commit 47bf118665a3("ofproto: Always set MTU for
> new internal ports."):
>
> a) When an internal interface is added, or its MTU has changed we
> overwrite its MTU with the bridge minimum.
> b) When a non internal, non tunnel port is added, we reconfigure every
> internal interface to match exactly the bridge minimum, no matter what
> c) If the bridge doesn't have physical ports (only tunnels and
> internals), we consider the minimum mtu to be 1500. We therefore force every
> internal interface to be 1500.
>
> Behavior b is the same. Behavior a is changed to match more closely behavior
> b. Behavior c is changed completely. Now the current configuration doesn't
> depend on the previous state.
> When I made the change I didn't think that there were valid use cases for
> allowing the user to configure internal interfaces MTU. The test suite
> obviously proved me wrong.
This is not the first time that this has come up, for example, a
couple months back:
http://openvswitch.org/pipermail/dev/2016-June/073190.html
The existing behavior is a legacy of trying to behave more similarly
to the Linux bridge a long time ago when users were trying to easily
swap between it and OVS. However, in practice the two aren't that
similar since OVS allows arbitrary partitioning of bridges through
flows in ways that could effectively make the pieces into separate
networks with different MTUs, imposing tags, etc. At the time, the
bridge didn't even have native support for VLANs, so none of this
could have been an issue.
If we could go back, I wish that we hadn't carried this behavior into
OVS. For people adjusting MTUs, it probably wouldn't have been a big
deal to adjust the OVS bridge MTU as well - the same as what is
necessary for VMs. However, I think that simply removing it at this
point will break some existing setups that I'm pretty sure exist in
the real world. If you have just a simple setup with an OVS bridge and
a physical Ethernet device with a non-default MTU, you are probably
relying on this automatic MTU adjustment.
So overall, I would be happy to move to the new model but I think this
patch is probably too aggressive in switching for the time being. I
think we need to keep the existing behavior as the default with a
switch and then maybe add some big deprecation warnings so we can
eventually change the default.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
