On 01/09/2016 11:07, "Jesse Gross" <je...@kernel.org> wrote:
>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.
Thanks for the detailed explanation Jesse, it makes more sense now.
>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.
You're right, it's probably not a good idea to change this behavior now.
Darrell suggested another approach, which at this point I think it's the
best way to go. We keep the old behavior, even if it was a little
inconsistent, for backwards compatibility. Since in this release we
also introduced 'mtu_request', we use that to override the old behavior
for internal ports. Users that are really interested in configuring
their internal port MTU can use that instead.
I don't like that mtu_request behaves differently than standard linux
tools, but I think this is a good balance between compatibility and
flexibility.
I've sent a series here:
http://openvswitch.org/pipermail/dev/2016-September/079078.html
http://openvswitch.org/pipermail/dev/2016-September/079079.html
Thanks,
Daniele
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
