netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edwin Peer <edwin.peer@broadcom.com>
To: netdev@vger.kernel.org
Cc: Edwin Peer <edwin.peer@broadcom.com>,
	edumazet@google.com, linville@tuxdriver.com,
	shemminger@vyatta.com, mirq-linux@rere.qmqm.pl,
	jesse.brandeburg@intel.com, jchapman@katalix.com,
	david@weave.works, j.vosburgh@gmail.com, vfalico@gmail.com,
	andy@greyhouse.net, sridhar.samudrala@intel.com,
	jiri@mellanox.com, geoff@infradead.org, mokuno@sm.sony.co.jp,
	msink@permonline.ru, mporter@kernel.crashing.org,
	inaky.perez-gonzalez@intel.com, jwi@linux.ibm.com,
	kgraul@linux.ibm.com, ubraun@linux.ibm.com,
	grant.likely@secretlab.ca, hadi@cyberus.ca, dsahern@kernel.org,
	shrijeet@gmail.com, jon.mason@intel.com, dave.jiang@intel.com,
	saeedm@mellanox.com, hadarh@mellanox.com, ogerlitz@mellanox.com,
	allenbh@gmail.com, michael.chan@broadcom.com
Subject: [RFC PATCH net-next 07/11] net: gre: constrain upper VLAN MTU using IFF_NO_VLAN_ROOM
Date: Wed, 27 May 2020 14:25:08 -0700	[thread overview]
Message-ID: <20200527212512.17901-8-edwin.peer@broadcom.com> (raw)
In-Reply-To: <20200527212512.17901-1-edwin.peer@broadcom.com>

Constrain the MTU of upper VLAN devices if the MTU of the GRE device
is configured to its default optimal size, which does not leave space
for a nested VLAN tag without causing fragmentation. If the underlying
lower device is not known, then the worst case is assumed and any upper
VLAN devices will always be adjusted to accommodate the VLAN tag.

For IPv4 tunnels, the changes to support this are made in the generic
ip_tunnel_change_mtu() handler and so IFF_NO_VLAN_ROOM is consequently
maintained for all tunnel devices that leverage this implementation. GRE
is, however, the only one of these implementations that might use an L2
overlay. At present nothing prevents VLAN devices being layered above
raw IP tunnel devices, which does not make sense. This limitation will
be addressed by a later patch in this series.

IPv6 GRE is dependent on PMTU discovery, but the MTU of nested VLANs
still need to be constrained, because non-VLAN packets will share the
same path MTU.

Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
---
 net/ipv4/ip_tunnel.c | 2 ++
 net/ipv6/ip6_gre.c   | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index f4f1d11eab50..21803bd35ab3 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -981,6 +981,7 @@ int __ip_tunnel_change_mtu(struct net_device *dev, int new_mtu, bool strict)
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	int t_hlen = tunnel->hlen + sizeof(struct iphdr);
 	int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+	int best_mtu = ip_tunnel_bind_dev(dev);
 
 	if (new_mtu < ETH_MIN_MTU)
 		return -EINVAL;
@@ -993,6 +994,7 @@ int __ip_tunnel_change_mtu(struct net_device *dev, int new_mtu, bool strict)
 	}
 
 	dev->mtu = new_mtu;
+	__vlan_constrain_mtu(dev, best_mtu);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(__ip_tunnel_change_mtu);
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 781ca8c07a0d..0b86ee7f3d31 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1131,6 +1131,8 @@ static void ip6gre_tnl_link_config_route(struct ip6_tnl *t, int set_mtu,
 
 				if (dev->mtu < IPV6_MIN_MTU)
 					dev->mtu = IPV6_MIN_MTU;
+
+				dev->priv_flags |= IFF_NO_VLAN_ROOM;
 			}
 		}
 		ip6_rt_put(rt);
@@ -1801,7 +1803,7 @@ static int ip6gre_tap_init(struct net_device *dev)
 	if (ret)
 		return ret;
 
-	dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+	dev->priv_flags |= IFF_LIVE_ADDR_CHANGE | IFF_NO_VLAN_ROOM;
 
 	return 0;
 }
-- 
2.26.2


  parent reply	other threads:[~2020-05-27 21:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 21:25 [RFC PATCH net-next 00/11] Nested VLANs - decimate flags and add another Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 01/11] net: geneve: enable vlan offloads Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 02/11] net: do away with the IFF_XMIT_DST_RELEASE_PERM flag Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 03/11] net: vlan: add IFF_NO_VLAN_ROOM to constrain MTU Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 04/11] net: geneve: constrain upper VLAN MTU using IFF_NO_VLAN_ROOM Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 05/11] net: vxlan: " Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 06/11] net: l2tp_eth: " Edwin Peer
2020-05-27 21:25 ` Edwin Peer [this message]
2020-05-27 21:25 ` [RFC PATCH net-next 08/11] net: distribute IFF_NO_VLAN_ROOM into aggregate devs Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 09/11] net: ntb_netdev: support VLAN using IFF_NO_VLAN_ROOM Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 10/11] net: vlan: disallow non-Ethernet devices Edwin Peer
2020-05-27 21:25 ` [RFC PATCH net-next 11/11] net: leverage IFF_NO_VLAN_ROOM to limit NETIF_F_VLAN_CHALLENGED Edwin Peer
2020-05-28  0:15 ` [RFC PATCH net-next 00/11] Nested VLANs - decimate flags and add another Michał Mirosław
2020-05-28  0:39   ` Edwin Peer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200527212512.17901-8-edwin.peer@broadcom.com \
    --to=edwin.peer@broadcom.com \
    --cc=allenbh@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=dave.jiang@intel.com \
    --cc=david@weave.works \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=geoff@infradead.org \
    --cc=grant.likely@secretlab.ca \
    --cc=hadarh@mellanox.com \
    --cc=hadi@cyberus.ca \
    --cc=inaky.perez-gonzalez@intel.com \
    --cc=j.vosburgh@gmail.com \
    --cc=jchapman@katalix.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@mellanox.com \
    --cc=jon.mason@intel.com \
    --cc=jwi@linux.ibm.com \
    --cc=kgraul@linux.ibm.com \
    --cc=linville@tuxdriver.com \
    --cc=michael.chan@broadcom.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=mokuno@sm.sony.co.jp \
    --cc=mporter@kernel.crashing.org \
    --cc=msink@permonline.ru \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=saeedm@mellanox.com \
    --cc=shemminger@vyatta.com \
    --cc=shrijeet@gmail.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=ubraun@linux.ibm.com \
    --cc=vfalico@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).