netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: David Ahern <dsahern@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
Date: Sun, 26 Nov 2017 23:07:25 -0800	[thread overview]
Message-ID: <20171126230725.1fcc3b51@xeon-e3> (raw)
In-Reply-To: <aac2350d-3a10-c97f-939b-a32d5e300412@gmail.com>

On Sun, 26 Nov 2017 20:13:39 -0700
David Ahern <dsahern@gmail.com> 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 <stephen@networkplumber.org>
> > ---
> >  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.

  reply	other threads:[~2017-11-27  7:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 18:17 [PATCH RFC 0/2] veth, bridge, and GSO maximums Stephen Hemminger
2017-11-26 18:17 ` [PATCH RFC 1/2] br: add notifier for when bridge changes it " Stephen Hemminger
2017-11-26 18:17 ` [PATCH RFC 2/2] veth: propagate bridge GSO to peer Stephen Hemminger
2017-11-27  3:13   ` David Ahern
2017-11-27  7:07     ` Stephen Hemminger [this message]
2017-11-27 20:14       ` Solio Sarabia
2017-11-27 21:15         ` Stephen Hemminger
2017-11-28  1:42           ` Solio Sarabia
2017-11-28  2:02             ` David Ahern
2017-11-30  0:35               ` Solio Sarabia
2017-11-30 17:10                 ` Stephen Hemminger
2017-11-30 17:26                   ` Eric Dumazet
2017-11-30 17:36                     ` Stephen Hemminger
2017-11-30 17:38                     ` David Miller
2017-11-30 17:49                     ` Stephen Hemminger
2017-11-30 17:59                       ` Eric Dumazet
2017-11-30 18:08                         ` Stephen Hemminger
2017-11-30 18:10                           ` Eric Dumazet
2017-12-01 20:30               ` Stephen Hemminger
2017-11-30 15:47 ` [PATCH RFC 0/2] veth, bridge, and GSO maximums David Miller
2017-11-30 17:11   ` Stephen Hemminger
2017-11-30 20:50     ` Alexander Duyck

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=20171126230725.1fcc3b51@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=sthemmin@microsoft.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).