From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
Date: Thu, 30 Nov 2017 09:36:22 -0800
Message-ID: <20171130093622.2e520fcc@xeon-e3>
References: <20171126181749.19288-1-sthemmin@microsoft.com>
        <20171126181749.19288-3-sthemmin@microsoft.com>
        <aac2350d-3a10-c97f-939b-a32d5e300412@gmail.com>
        <20171126230725.1fcc3b51@xeon-e3>
        <20171127201419.GA79@intel.com>
        <20171127131502.1fbfaa66@xeon-e3>
        <20171128014222.GA503@intel.com>
        <91628267-2e48-a231-7cc2-4830eb95ceef@gmail.com>
        <20171130003534.GA60@intel.com>
        <20171130091021.658869b0@xeon-e3>
        <1512062799.19682.19.camel@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Solio Sarabia <solio.sarabia@intel.com>,
        David Ahern <dsahern@gmail.com>, davem@davemloft.net,
        netdev@vger.kernel.org, sthemmin@microsoft.com,
        shiny.sebastian@intel.com
To: Eric Dumazet <eric.dumazet@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pg0-f67.google.com ([74.125.83.67]:33809 "EHLO
        mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752792AbdK3Rga (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 30 Nov 2017 12:36:30 -0500
Received: by mail-pg0-f67.google.com with SMTP id j4so3283415pgp.1
        for <netdev@vger.kernel.org>; Thu, 30 Nov 2017 09:36:30 -0800 (PST)
In-Reply-To: <1512062799.19682.19.camel@gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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:
> >=20
> >=20
> > The problem goes back into the core GSO networking code.
> > Something like this is needed.
> >=20
> > static inline bool netif_needs_gso(struct sk_buff *skb,
> > 				=C2=A0=C2=A0=C2=A0const struct net_device *dev,
> > 				=C2=A0=C2=A0=C2=A0netdev_features_t features)
> > {
> > 	return skb_is_gso(skb) &&
> > 		(!skb_gso_ok(skb, features) ||
> > 		=C2=A0unlikely(skb_shinfo(skb)->gso_segs > dev- =20
> > >gso_max_segs) ||=C2=A0=C2=A0<< new =20
> > 		=C2=A0unlikely(skb_shinfo(skb)->gso_size > dev- =20
> > >gso_max_size) ||=C2=A0=C2=A0<< new =20
> > 		=C2=A0unlikely((skb->ip_summed !=3D CHECKSUM_PARTIAL) &&
> > 			=C2=A0=C2=A0(skb->ip_summed !=3D CHECKSUM_UNNECESSARY)));
> > }
> >=20
> > 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. =20
>=20
>=20
> Since very few drivers have these gso_max_segs / gso_max_size, check
> could be done in their ndo_features_check()

Agreed, we could do it there.