[ovs-dev] Odd gre_sys MTU setting (2.6.x vs 2.8.x)

Christian Ehrhardt christian.ehrhardt at canonical.com
Mon Jan 15 16:38:00 UTC 2018


>> Looks like the kernel is limiting to 1500.
>
> I would expect setting with ip-link to fail as well.
> What does the below show?:
>
>   $ ip link set dev gre_sys mtu 65535

For your question - we just talked about that and yes on the new
kernel that fails as well if set via ip.

But those checks are newer than kernel 4.4

Since
commit 61e84623ace35ce48975e8f90bbbac7557c43d61
Author: Jarod Wilson <jarod at redhat.com>
Date:   Fri Oct 7 22:04:33 2016 -0400

    net: centralize net_device min/max MTU checking

Any call is checked in net/core/dev.c and this is the message you saw.
Now there is another related change
commit a52ad514fdf3b8a57ca4322c92d2d8d5c6182485
Author: Jarod Wilson <jarod at redhat.com>
Date:   Fri Oct 7 22:04:34 2016 -0400

    net: deprecate eth_change_mtu, remove usage

Which essentially removes all the per device checks in favor of the
new central check.
In there it mentions that:
 ... All callers have been     audited for calls to alloc_etherdev* or
ether_setup directly, which means they all have a valid dev->min_mtu
and dev->max_mtu ...

Working theories for me atm are:
- gre formerly had no such check at al land worked, but the central
check kicks in and refuses to set the higher MTU
- This would either be a kernel bug on gre, or on the new OVS in case
the netlink based creation would be supposed to add something to set
the max_mtu accordingly.

The checks on MTU change essentially are those in core and a call to
the net_device_ops.ndo_change_mtu callback.
That is implemented in ip_tunnel_change_mtu by gre.
in 4.4 this was checking as:
    if (new_mtu < 68 ||
        new_mtu > 0xFFF8 - dev->hard_header_len - t_hlen)
        return -EINVAL;

The new check is not that much different it seems:
    int max_mtu = 0xFFF8 - dev->hard_header_len - t_hlen;

    if (new_mtu < ETH_MIN_MTU)
    return -EINVAL;

    if (new_mtu > max_mtu) {
        if (strict)
            return -EINVAL;

But that does not disable the central check.
And this only relies on the max_mtu values in the device struct

I still have to look what gro actually sets on initial setup, but atm
I'd assume it could do some default which might be 1500 or so and due
to that limits it later on our try to increase the value.


More information about the dev mailing list