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 I still don't understand how the MTU of other ports can be affected by this (and they didn't seem to be in my testing). Is it possible that there is something in Neutron that is doing this? In any case, the above code is the only logic that affects MTU in OVS that I am aware of, so maybe you can experiment with changing it and see if it fixes the problem. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
