| Message ID | 20160830184115.89303-2-diproiettod@vmware.com |
|---|---|
| State | Accepted |
| Headers | show |
On Tue, Aug 30, 2016 at 11:41:15AM -0700, Daniele Di Proietto wrote: > We only changed the MTU of new internal ports if it is bigger than the > bridge minimum. But when the minimum MTU of the bridge is updated we > change the MTU of all internal ports no matter what. > > The behavior is inconsistent, because now the internal ports MTU depends > on the order in which the ports where added. > > This commit fixes the problem by _always_ setting the MTU of new > internal ports to the bridge minimum. I'm not sure what was the logic > behind only adjusting the mtu if it was too big. > > A testcase is improved to detect the problem. > > VMware-BZ: #1718776 > Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com> Acked-by: Ben Pfaff <blp@ovn.org>
On 30/08/2016 15:32, "Ben Pfaff" <blp@ovn.org> wrote: >On Tue, Aug 30, 2016 at 11:41:15AM -0700, Daniele Di Proietto wrote: >> We only changed the MTU of new internal ports if it is bigger than the >> bridge minimum. But when the minimum MTU of the bridge is updated we >> change the MTU of all internal ports no matter what. >> >> The behavior is inconsistent, because now the internal ports MTU depends >> on the order in which the ports where added. >> >> This commit fixes the problem by _always_ setting the MTU of new >> internal ports to the bridge minimum. I'm not sure what was the logic >> behind only adjusting the mtu if it was too big. >> >> A testcase is improved to detect the problem. >> >> VMware-BZ: #1718776 >> Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com> > >Acked-by: Ben Pfaff <blp@ovn.org> Thanks for the prompt reviews, I applied the series to master and branch-2.6
On 30/08/2016 18:06, "Daniele Di Proietto" <diproiettod@vmware.com> wrote: > > > > > >On 30/08/2016 15:32, "Ben Pfaff" <blp@ovn.org> wrote: > >>On Tue, Aug 30, 2016 at 11:41:15AM -0700, Daniele Di Proietto wrote: >>> We only changed the MTU of new internal ports if it is bigger than the >>> bridge minimum. But when the minimum MTU of the bridge is updated we >>> change the MTU of all internal ports no matter what. >>> >>> The behavior is inconsistent, because now the internal ports MTU depends >>> on the order in which the ports where added. >>> >>> This commit fixes the problem by _always_ setting the MTU of new >>> internal ports to the bridge minimum. I'm not sure what was the logic >>> behind only adjusting the mtu if it was too big. >>> >>> A testcase is improved to detect the problem. >>> >>> VMware-BZ: #1718776 >>> Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com> >> >>Acked-by: Ben Pfaff <blp@ovn.org> > >Thanks for the prompt reviews, I applied the series to master and branch-2.6 Unfortunately this patch broke the system testsuite. I proposed a fix here, but it involves changing a long standing behavior of Open vSwitch. http://openvswitch.org/pipermail/dev/2016-August/078931.html
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c index da7372d..9d62b72 100644 --- a/ofproto/ofproto.c +++ b/ofproto/ofproto.c @@ -281,6 +281,8 @@ static void meter_insert_rule(struct rule *); /* unixctl. */ static void ofproto_unixctl_init(void); +static int find_min_mtu(struct ofproto *p); + /* All registered ofproto classes, in probe order. */ static const struct ofproto_class **ofproto_classes; static size_t n_ofproto_classes; @@ -514,7 +516,7 @@ ofproto_create(const char *datapath_name, const char *datapath_type, hmap_init(&ofproto->learned_cookies); ovs_list_init(&ofproto->expirable); ofproto->connmgr = connmgr_create(ofproto, datapath_name, datapath_name); - ofproto->min_mtu = INT_MAX; + ofproto->min_mtu = find_min_mtu(ofproto); cmap_init(&ofproto->groups); ovs_mutex_unlock(&ofproto_mutex); ofproto->ogf.types = 0xf; @@ -2750,10 +2752,8 @@ update_mtu(struct ofproto *p, struct ofport *port) return; } if (ofport_is_internal(p, port)) { - if (dev_mtu > p->min_mtu) { - if (!netdev_set_mtu(port->netdev, p->min_mtu)) { - dev_mtu = p->min_mtu; - } + if (!netdev_set_mtu(port->netdev, p->min_mtu)) { + dev_mtu = p->min_mtu; } port->mtu = dev_mtu; return; diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at index d7705da..8e5fde6 100644 --- a/tests/ofproto-dpif.at +++ b/tests/ofproto-dpif.at @@ -8863,6 +8863,11 @@ AT_CLEANUP AT_SETUP([ofproto - set mtu]) OVS_VSWITCHD_START +# Check that initial MTU is 1500 for 'br0'. +AT_CHECK([ovs-vsctl get Interface br0 mtu], [0], [dnl +1500 +]) + add_of_ports br0 1 # Check that initial MTU is 1500 for 'br0' and 'p1'. @@ -8892,5 +8897,9 @@ AT_CHECK([ovs-vsctl add-port br0 p2 -- set int p2 type=dummy mtu_request=1600]) AT_CHECK([ovs-vsctl --timeout=10 wait-until Interface p2 mtu=1600]) AT_CHECK([ovs-vsctl --timeout=10 wait-until Interface br0 mtu=1600]) +# New internal port. The MTU should be updated even for a newly added port. +AT_CHECK([ovs-vsctl add-port br0 int1 -- set int int1 type=internal]) +AT_CHECK([ovs-vsctl --timeout=10 wait-until Interface int1 mtu=1600]) + OVS_VSWITCHD_STOP AT_CLEANUP
We only changed the MTU of new internal ports if it is bigger than the bridge minimum. But when the minimum MTU of the bridge is updated we change the MTU of all internal ports no matter what. The behavior is inconsistent, because now the internal ports MTU depends on the order in which the ports where added. This commit fixes the problem by _always_ setting the MTU of new internal ports to the bridge minimum. I'm not sure what was the logic behind only adjusting the mtu if it was too big. A testcase is improved to detect the problem. VMware-BZ: #1718776 Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com> --- ofproto/ofproto.c | 10 +++++----- tests/ofproto-dpif.at | 9 +++++++++ 2 files changed, 14 insertions(+), 5 deletions(-)