[PATCH 0/2] Allow changing device gso maximums

Docker uses bridge/veth for its bridged network. veth sends tcp packets
as big as 65536 (its default gso value), even when lower physical or
synthetic devices expose a lower limit. This causes tcp fragmentation in
the host, spinning more cpu cycles.

The proposed solution is to allow user to tune gso settings, via iproute
utils for example. Note: this enables changing gso for all interfaces,
not limited to veth only.

This series rebases Stephen's original patches [1]. It also fixes a
minor issue when validating maximum gso_max_size, which can be in the
range [0,65536]. Changes are validated with and without docker use
cases.

[1] https://marc.info/?l=linux-netdev&m=151217101428494&w=2

Stephen Hemminger (2):
  rtnetlink: allow GSO maximums to be passed to device
  veth: allow configuring GSO maximums

 drivers/net/veth.c   | 20 ++++++++++++++++++++
 net/core/rtnetlink.c | 30 ++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

-- 
2.7.4

From: Stephen Hemminger <stephen@networkplumber.org>

Allow GSO maximum segments and size as netlink parameters on input,
with 'ip link add' utils for example. Allow also updating these
attributes after rtnetlink devices are created.

Signed-off-by: Stephen Hemminger <redacted>
Signed-off-by: Solio Sarabia <redacted>
---
 net/core/rtnetlink.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a4faefd..a1ff2a8 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c

@@ -1637,6 +1637,8 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
 	[IFLA_PROMISCUITY]	= { .type = NLA_U32 },
 	[IFLA_NUM_TX_QUEUES]	= { .type = NLA_U32 },
 	[IFLA_NUM_RX_QUEUES]	= { .type = NLA_U32 },
+	[IFLA_GSO_MAX_SEGS]	= { .type = NLA_U32 },
+	[IFLA_GSO_MAX_SIZE]	= { .type = NLA_U32 },
 	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
 	[IFLA_CARRIER_CHANGES]	= { .type = NLA_U32 },  /* ignored */
 	[IFLA_PHYS_SWITCH_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },

@@ -2287,6 +2289,34 @@ static int do_setlink(const struct sk_buff *skb,
 		}
 	}
 
+	if (tb[IFLA_GSO_MAX_SIZE]) {
+		u32 max_size = nla_get_u32(tb[IFLA_GSO_MAX_SIZE]);
+
+		if (max_size > GSO_MAX_SIZE) {
+			err = -EINVAL;
+			goto errout;
+		}
+
+		if (dev->gso_max_size ^ max_size) {
+			netif_set_gso_max_size(dev, max_size);
+			status |= DO_SETLINK_MODIFIED;
+		}
+	}
+
+	if (tb[IFLA_GSO_MAX_SEGS]) {
+		u32 max_segs = nla_get_u32(tb[IFLA_GSO_MAX_SEGS]);
+
+		if (max_segs > GSO_MAX_SEGS) {
+			err = -EINVAL;
+			goto errout;
+		}
+
+		if (dev->gso_max_segs ^ max_segs) {
+			dev->gso_max_segs = max_segs;
+			status |= DO_SETLINK_MODIFIED;
+		}
+	}
+
 	if (tb[IFLA_OPERSTATE])
 		set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
 

-- 
2.7.4

From: Stephen Hemminger <stephen@networkplumber.org>

Veth's can be used in environments (like Azure) where the underlying
network device is impacted by large GSO packets. This patch allows
gso maximum values to be passed in when creating the device via
netlink.

In theory, other pseudo devices could also use netlink attributes
to set GSO maximums but for now veth is what has been observed
to be an issue.

Signed-off-by: Stephen Hemminger <redacted>
Signed-off-by: Solio Sarabia <redacted>
---
 drivers/net/veth.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index f5438d0..510c058 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c

@@ -410,6 +410,26 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
 	if (ifmp && (dev->ifindex != 0))
 		peer->ifindex = ifmp->ifi_index;
 
+	if (tbp[IFLA_GSO_MAX_SIZE]) {
+		u32 max_size = nla_get_u32(tbp[IFLA_GSO_MAX_SIZE]);
+
+		if (max_size > GSO_MAX_SIZE)
+			return -EINVAL;
+
+		peer->gso_max_size = max_size;
+		dev->gso_max_size = max_size;
+	}
+
+	if (tbp[IFLA_GSO_MAX_SEGS]) {
+		u32 max_segs = nla_get_u32(tbp[IFLA_GSO_MAX_SEGS]);
+
+		if (max_segs > GSO_MAX_SEGS)
+			return -EINVAL;
+
+		peer->gso_max_segs = max_segs;
+		dev->gso_max_segs = max_segs;
+	}
+
 	err = register_netdevice(peer);
 	put_net(net);
 	net = NULL;

-- 
2.7.4

On Tue,  5 Dec 2017 17:14:26 -0800
Solio Sarabia [off-list ref] wrote:

From: Stephen Hemminger <stephen@networkplumber.org>

Veth's can be used in environments (like Azure) where the underlying
network device is impacted by large GSO packets. This patch allows
gso maximum values to be passed in when creating the device via
netlink.

In theory, other pseudo devices could also use netlink attributes
to set GSO maximums but for now veth is what has been observed
to be an issue.

Signed-off-by: Stephen Hemminger <redacted>
Signed-off-by: Solio Sarabia <redacted>

I am testing new version with changelink support

On Tue, Dec 05, 2017 at 05:25:10PM -0800, Stephen Hemminger wrote:

On Tue,  5 Dec 2017 17:14:26 -0800
Solio Sarabia [off-list ref] wrote:

quoted

From: Stephen Hemminger <stephen@networkplumber.org>

Veth's can be used in environments (like Azure) where the underlying
network device is impacted by large GSO packets. This patch allows
gso maximum values to be passed in when creating the device via
netlink.

In theory, other pseudo devices could also use netlink attributes
to set GSO maximums but for now veth is what has been observed
to be an issue.

Signed-off-by: Stephen Hemminger <redacted>
Signed-off-by: Solio Sarabia <redacted>

I am testing new version with changelink support

Ack, I second whatever version works best.
Will help to try newer patches.