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.
---------
Proposed solution:
A) This patch.
Since OVS is not able the control the MTU in case of tunnelling or MPLS,
stop doing it entirely. The systems that relied on the old behavior need to be
updated.
B) We could consider an hybrid solution that keeps backwards compatibility for
tunnelling use cases (like our testsuite).
2a)
2b or 1b)
1c)
This would not solve the problem for MPLS. MPLS uses physical devices, so
the internal interface would be forced to match the physical interfaces and
this is not OK for MPLS (or double vlans). Also, this solution keeps behavior
1c, which makes the mtu assignment "stateful".
Other ideas?
Thanks,
Daniele
On 31/08/2016 21:02, "Darrell Ball" <dlu...@gmail.com> wrote:
>
>
>On Wed, Aug 31, 2016 at 6:48 PM, Joe Stringer
><j...@ovn.org> wrote:
>
>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.
>
>
>
>
>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@openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev
>
>
>
>
>
>
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
