Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer

[Eric Dumazet <eric.dumazet@gmail.com>]

On Thu, 2017-11-30 at 10:08 -0800, Stephen Hemminger wrote:
> On Thu, 30 Nov 2017 09:59:23 -0800
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
> > On Thu, 2017-11-30 at 09:49 -0800, Stephen Hemminger wrote:
> > > On Thu, 30 Nov 2017 09:26:39 -0800
> > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >   
> > > > On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:  
> > > > > 
> > > > > 
> > > > > The problem goes back into the core GSO networking code.
> > > > > Something like this is needed.
> > > > > 
> > > > > static inline bool netif_needs_gso(struct sk_buff *skb,
> > > > > 				   const struct net_device
> > > > > *dev,
> > > > > 				   netdev_features_t features)
> > > > > {
> > > > > 	return skb_is_gso(skb) &&
> > > > > 		(!skb_gso_ok(skb, features) ||
> > > > > 		 unlikely(skb_shinfo(skb)->gso_segs > dev-    
> > > > > > gso_max_segs) ||  << new    
> > > > > 
> > > > > 		 unlikely(skb_shinfo(skb)->gso_size > dev-    
> > > > > > gso_max_size) ||  << new    
> > > > > 
> > > > > 		 unlikely((skb->ip_summed != CHECKSUM_PARTIAL)
> > > > > &&
> > > > > 			  (skb->ip_summed !=
> > > > > CHECKSUM_UNNECESSARY)));
> > > > > }
> > > > > 
> > > > > What that will do is split up the monster GSO packets if they
> > > > > ever
> > > > > bleed
> > > > > across from one device to another through the twisty mazes of
> > > > > packet
> > > > > processing paths.    
> > > > 
> > > > 
> > > > Since very few drivers have these gso_max_segs / gso_max_size,
> > > > check
> > > > could be done in their ndo_features_check()  
> > > 
> > > Actually, we already check for max_segs, just missing check for
> > > size
> > > here:
> > > 
> > > From 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00
> > > 2001
> > > From: Stephen Hemminger <sthemmin@microsoft.com>
> > > Date: Thu, 30 Nov 2017 09:45:11 -0800
> > > Subject: [PATCH] net: do not GSO if frame is too large
> > > 
> > > This adds an additional check to breakup skb's that exceed a
> > > devices
> > > GSO maximum size. The code was already checking for too many
> > > segments
> > > but did not check size.
> > > 
> > > This has been observed to be a problem when using containers on
> > > Hyper-V/Azure where the allowed GSO maximum size is less than
> > > maximum and skb's have gone through multiple layers to arrive
> > > at the virtual device.
> > > 
> > > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > > ---
> > >  net/core/dev.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 07ed21d64f92..0bb398f3bfa3 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -2918,9 +2918,11 @@ static netdev_features_t
> > > gso_features_check(const struct sk_buff *skb,
> > >  					    struct net_device
> > > *dev,
> > >  					    netdev_features_t
> > > features)
> > >  {
> > > +	unsigned int gso_size = skb_shinfo(skb)->gso_size;
> > >  	u16 gso_segs = skb_shinfo(skb)->gso_segs;
> > >  
> > > -	if (gso_segs > dev->gso_max_segs)
> > > +	if (gso_segs > dev->gso_max_segs ||
> > > +	    gso_size > dev->gso_max_size)
> > >  		return features & ~NETIF_F_GSO_MASK;
> > >  
> > >  	/* Support for GSO partial features requires software  
> > 
> > 
> > Yes, but check commit 743b03a83297690f0bd38c452a3bbb47d2be300a
> > ("net: remove netdevice gso_min_segs")
> > 
> > Plan was to get rid of the existing check, not adding new ones :/
> 
> Sure can do it in the driver and that has other benefits like ability
> to backport to older distributions.
> 
> Still need gso_max_size though since want to tell TCP to avoid
> generating mega-jumbo frames.
> 

Sure, the netdev->gso_max_{size|segs} are staying.

I was simply trying to not add another check in fast path :/

Thanks.