From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer Date: Sun, 26 Nov 2017 23:07:25 -0800 Message-ID: <20171126230725.1fcc3b51@xeon-e3> References: <20171126181749.19288-1-sthemmin@microsoft.com> <20171126181749.19288-3-sthemmin@microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger To: David Ahern Return-path: Received: from mail-pl0-f67.google.com ([209.85.160.67]:42192 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751120AbdK0HHd (ORCPT ); Mon, 27 Nov 2017 02:07:33 -0500 Received: by mail-pl0-f67.google.com with SMTP id z3so7948687plh.9 for ; Sun, 26 Nov 2017 23:07:33 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Sun, 26 Nov 2017 20:13:39 -0700 David Ahern wrote: > On 11/26/17 11:17 AM, Stephen Hemminger wrote: > > This allows veth device in containers to see the GSO maximum > > settings of the actual device being used for output. > > > > Signed-off-by: Stephen Hemminger > > --- > > drivers/net/veth.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 72 insertions(+) > > > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > > index f5438d0978ca..0c9ce156943b 100644 > > --- a/drivers/net/veth.c > > +++ b/drivers/net/veth.c > > @@ -511,17 +511,89 @@ static struct rtnl_link_ops veth_link_ops = { > > .get_link_net = veth_get_link_net, > > }; > > > > +/* When veth device is added to a bridge or other master device > > + * then reflect the GSO max values from the upper device > > + * to the other end of veth pair. > > + */ > > +static void veth_change_upper(struct net_device *dev, > > + const struct netdev_notifier_changeupper_info *info) > > +{ > > + struct net_device *upper = info->upper_dev; > > + struct net_device *peer; > > + struct veth_priv *priv; > > + > > + if (dev->netdev_ops != &veth_netdev_ops) > > + return; > > + > > + priv = netdev_priv(dev); > > + peer = rtnl_dereference(priv->peer); > > + if (!peer) > > + return; > > + > > + if (upper) { > > + peer->gso_max_segs = upper->gso_max_segs; > > + peer->gso_max_size = upper->gso_max_size; > > + } else { > > + peer->gso_max_segs = GSO_MAX_SEGS; > > + peer->gso_max_size = GSO_MAX_SIZE; > > + } > > veth devices can be added to a VRF instead of a bridge, and I do not > believe the gso propagation works for L3 master devices. > > From a quick grep, team devices do not appear to handle gso changes either. This code should still work correctly, but no optimization would happen. The gso_max_size of the VRF or team will still be GSO_MAX_SIZE so there would be no change. If VRF or Team ever got smart enough to handle GSO limits, then the algorithm would handle it.