On Tue, Jun 28, 2016 at 8:53 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > >> On 28 Jun 2016, at 17:41, Jesse Gross <je...@kernel.org> wrote: >> >> On Tue, Jun 28, 2016 at 1:37 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >>> >>>> On 27 Jun 2016, at 23:57, Jesse Gross <je...@kernel.org> wrote: >>>> >>>> On Tue, Jun 21, 2016 at 10:16 PM, Ihar Hrachyshka <ihrac...@redhat.com> >>>> wrote: >>>>>> On 21 Jun 2016, at 23:46, Jesse Gross <je...@kernel.org> wrote: >>>>>> On Mon, Jun 20, 2016 at 5:16 AM, Ihar Hrachyshka <ihrac...@redhat.com> >>>>>> wrote: >>>>>>> So back to MTU. When I boot a VM using a VXLAN backed network, the tap >>>>>>> device of MTU=1450 is plugged into the br-int bridge, which lowers the >>>>>>> bridge MTU to 1450. Then when I plug a device that belongs to a GRE >>>>>>> network (MTU = 1458) into that same bridge, the GRE network backed >>>>>>> device also gets its MTU reduced to 1450, and no ‘ip link’ commands >>>>>>> allow to raise it to the intended MTU=1458. >>>>>> >>>>>> I'm not sure I fully understand the scenario. The part about having >>>>>> multiple, effectively independent networks on the same bridge I >>>>>> understand. I also understand how the bridge device's MTU is lowered >>>>>> to the minimum of the ports attached to the bridge. >>>>>> >>>>>> The part about the tunnel device MTU sounds weird to me. Are these >>>>>> tunnel ports that have been created through OVSDB? Or are they created >>>>>> separately through something like ip link and then attached to OVS >>>>>> just as if they were regular Ethernet devices? >>>>> >>>>> For the sake of the integration bridge, there is no difference between >>>>> tunnelled networks and e.g. vlan networks. They are the same tap devices >>>>> connected to the bridge. The only difference between them is that they >>>>> should have different MTUs set. >>>>> >>>>> (In Neutron, traffic from tunnelled devices that is meant for routing is >>>>> redirected to another bridge (br-tun) connected via a patch port where >>>>> routing actually happens.) The tunnelling bridge is also implemented as >>>>> an Open vSwitch bridge. >>>>> >>>>>> >>>>>> In the former case, the ports essentially have infinite MTU so this >>>>>> shouldn't come up at all. And in the latter case, the ports don't even >>>>>> know that they are attached to OVS. (If this is happening, what occurs >>>>>> when you try to change the MTU with ip link? Do you get an error or it >>>>>> just doesn't work?) >>>>>> >>>>> >>>>> As I said above, tunneling is implemented by a separate bridge. >>>>> >>>>> The correct MTU of devices is especially relevant for our routers >>>>> (network namespaces) where the MTU value on an internal port connecting >>>>> the router to the integration bridge influences how the router fragment >>>>> packets coming from its other legs (internal or external). >>>>> >>>>> When I try to set MTU with ip link on ports plugged into the integration >>>>> bridge, it just doesn’t work if the desired MTU is higher than the bridge >>>>> MTU (which is already the lowest of all other devices plugged into the >>>>> bridge). No error produced. But when I move the device into a network >>>>> namespace, it suddenly start to work, allowing any MTU to be set. >>>> >>>> I guess I'm having a hard time understanding exactly what is happening >>>> based on your description. It's not clear to me whether there is a >>>> problem with changing the MTUs of the attached ports or just the >>>> effect that it has on the MTU of the internal device. >>> >>> Yes, I can’t raise MTU on attached ports, neither on the bridge itself. I >>> can lower it though (and revert back to the previous value). >>> >>>> >>>> I'm guessing that this is just the internal device - that's the >>>> intention of the code and I also tested to make sure that's what >>>> happens in practice. Presumably any other changes to MTUs are done by >>>> Neutron since OVS should not influence them. >>>> >>>> In terms of the internal device, I agree that this MTU adjustment >>>> doesn't necessarily make sense in an OVS context. It was carried over >>>> from the Linux bridge but OVS allows the network to be divided up in a >>>> much more arbitrary manner. >>>> >>>> I think the cleanest way to deal with this is to retain the MTU if the >>>> user sets it manually and not continue to make changes automatically. >>>> This would avoid adding a fairly obscure configuration option. The >>>> main problem that I see is ensuring that the MTU doesn't get reset in >>>> the event of an OVS restart. Perhaps you can find a clean way to do >>>> that. >>> >>> Sadly I am not a kernel developer (well, I was once, but that was a quite >>> long time ago). I can only suggest to relax the requirement, maybe pull >>> some resources into fixing it. But first thing, I would like to get to an >>> agreement on the direction we can take here. If that’s to fulfil all MTU >>> set requests, I am fine with it, and may start looking into getting a patch >>> up for review for just that. >> >> The code to control the MTU of the bridge device is actually in OVS >> userspace, not the kernel. Here is the main hunk: >> https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto.c#L2771 > > Doesn’t this loop update MTU for all devices plugged into a bridge to the > lowest of all? > https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto.c#L2810
Inside that loop is a check for whether the port is an internal device. Internal devices are either the bridge port or other ports create with interface type=internal. As a result, it shouldn't apply to things like tap devices. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
