Hi Darrel, thanks for your comments
Replies inline 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. This patch completely removes the default behavior. I think it's the cleanest solution, even though I'm worried about compatibility. >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