From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer Date: Thu, 30 Nov 2017 12:38:22 -0500 (EST) Message-ID: <20171130.123822.578491882910143968.davem@davemloft.net> References: <20171130003534.GA60@intel.com> <20171130091021.658869b0@xeon-e3> <1512062799.19682.19.camel@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Cc: stephen@networkplumber.org, solio.sarabia@intel.com, dsahern@gmail.com, netdev@vger.kernel.org, sthemmin@microsoft.com, shiny.sebastian@intel.com To: eric.dumazet@gmail.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:47780 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdK3RiY (ORCPT ); Thu, 30 Nov 2017 12:38:24 -0500 In-Reply-To: <1512062799.19682.19.camel@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Eric Dumazet Date: Thu, 30 Nov 2017 09:26:39 -0800 > 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() Agreed.