From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH net v2 0/2] ip[6] tunnels: fix mtu calculations
Date: Fri, 01 Jun 2018 13:57:41 -0400 (EDT)
Message-ID: <20180601.135741.863528561800652928.davem@davemloft.net>
References: <20180530202904.GA23937@splinter>
        <20180531085933.31079-1-nicolas.dichtel@6wind.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: petrm@mellanox.com, idosch@mellanox.com, netdev@vger.kernel.org
To: nicolas.dichtel@6wind.com
Return-path: <netdev-owner@vger.kernel.org>
Received: from shards.monkeyblade.net ([184.105.139.130]:49810 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752108AbeFAR5o (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 1 Jun 2018 13:57:44 -0400
In-Reply-To: <20180531085933.31079-1-nicolas.dichtel@6wind.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 31 May 2018 10:59:31 +0200

> The first patch restores the possibility to bind an ip4 tunnel to an
> interface whith a large mtu.
> The second patch was spotted after the first fix. I also target it to net
> because it fixes the max mtu value that can be used for ipv6 tunnels.
> 
> v2: remove the 0xfff8 in ip_tunnel_newlink()

Series applied and queued up for -stable.

I think the 0xfff8 value might come from the requirement that ipv6
fragments need to be a multiple of 8 bytes long.