Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <GtgHtyGO5jHKHT6zGMAzg3TDejXZT0HMQVoqNERZRdM@cp3-web-024.plabs.ch>
 <CA+FuTSd1H6+NjSDcin6KQo9y1KEsDACeAvyr0p5JuDWc-aEh+A@mail.gmail.com> <4e2CSI69yKQIvZp3Wwo9pC9lHNAz4osj7w8OdhYUdE@cp7-web-042.plabs.ch>
In-Reply-To: <4e2CSI69yKQIvZp3Wwo9pC9lHNAz4osj7w8OdhYUdE@cp7-web-042.plabs.ch>
From:   Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date:   Mon, 2 Nov 2020 15:04:37 -0500
Message-ID: <CA+FuTSeY7cMKqU_KGoxGJGp1vSiLJ9vUxrh9hoJHQg31W6fYtA@mail.gmail.com>
Subject: Re: [PATCH v2 net-next 2/2] net: bonding, dummy, ifb, team: advertise NETIF_F_GSO_SOFTWARE
To:     Alexander Lobakin <alobakin@pm.me>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Jay Vosburgh <j.vosburgh@gmail.com>,
        Veaceslav Falico <vfalico@gmail.com>,
        Andy Gospodarek <andy@greyhouse.net>,
        Jiri Pirko <jiri@resnulli.us>,
        Steffen Klassert <steffen.klassert@secunet.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Antoine Tenart <atenart@kernel.org>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Nov 2, 2020 at 2:26 PM Alexander Lobakin <alobakin@pm.me> wrote:
>
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Mon, 2 Nov 2020 11:30:17 -0500
>
> Hi!
> Thanks for the Ack.
>
> > On Sun, Nov 1, 2020 at 8:17 AM Alexander Lobakin <alobakin@pm.me> wrote:
> >>
> >> Virtual netdevs should use NETIF_F_GSO_SOFTWARE to forward GSO skbs
> >> as-is and let the final drivers deal with them when supported.
> >> Also remove NETIF_F_GSO_UDP_L4 from bonding and team drivers as it's
> >> now included in the "software" list.
> >
> > The rationale is that it is okay to advertise these features with
> > software fallback as bonding/teaming "hardware" features, because
> > there will always be a downstream device for which they will be
> > implemented, possibly in the software fallback, correct?
> >
> > That does not apply to dummy or IFB. I guess dummy is fine, because
> > xmit is a black hole, and IFB because ingress can safely handle these
> > packets? How did you arrive at the choice of changing these two, of
> > all virtual devices?
>
> Two points:
> 1. Exactly, dummy is just dummy, while ifb is an intermediate netdev to
>    share resources, so it should be as fine as with other virtual devs.
> 2. They both advertise NETIF_F_ALL_TSO | NETIF_F_GSO_ENCAP_ALL, which
>    assumes that they handle all GSO skbs just like the others (pass
>    them as is to the real drivers in case with ifb).

There is no real driver in the case of ifb if it forwards to the
ingress path. But as discussed before, that can handle gso packets for
all these protocols, too.

> >>
> >> Suggested-by: Willem de Bruijn <willemb@google.com>
> >> Signed-off-by: Alexander Lobakin <alobakin@pm.me>

Acked-by: Willem de Bruijn <willemb@google.com>