>> 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 <ja...@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 <ja...@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. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev