Hi Joe, Thanks for your comments
replies inline On 31/08/2016 18:48, "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. That's correct >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. Yes >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? I think so >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. That's exactly what's happening after this patch. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev