netdev - Re: [PATCH RFC 0/3] Support fraglist GRO/GSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAF=yD-+=Po31KUDexGA6V+heNF4xRc1bOwiyQ3xd9G2UmoKVVg@mail.gmail.com>
Date:   Mon, 28 Jan 2019 11:46:22 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH RFC 0/3] Support fraglist GRO/GSO

On Mon, Jan 28, 2019 at 2:51 AM Steffen Klassert
<steffen.klassert@...unet.com> wrote:
>
> On Fri, Jan 25, 2019 at 08:57:00AM -0500, Willem de Bruijn wrote:
> > On Fri, Jan 25, 2019 at 3:14 AM Steffen Klassert
> > <steffen.klassert@...unet.com> wrote:
> > >
> > > On Mon, Jan 14, 2019 at 12:09:22PM -0500, Willem de Bruijn wrote:
> > > > On Mon, Jan 14, 2019 at 7:50 AM Steffen Klassert
> > > > <steffen.klassert@...unet.com> wrote:
> > > > > On Sun, Dec 23, 2018 at 08:15:40PM -0500, Willem de Bruijn wrote:
> > > >
> > > > I don't think that the route lookup is needed. If listified is cheaper
> > > > for local delivery, too, then we can make that the default unless a
> > > > device is active with h/w offload and ip forwarding is enabled. If it
> > > > isn't, then use it iff ip forwarding is enabled. I think it's fine to
> > > > mispredict between the two in edge cases with netfilter mangling, as
> > > > long as all paths can correctly handle both types of GRO packets.
> > >
> > > I'd need at least a route lookup for my usecase, because listified
> > > GRO is always cheaper when a xfrm transformation is needed (even for
> > > TCP). In this case is software GSO needed. So I'd need to either have
> > > an early route lookup or maybe some early ingress hook where a route
> > > lookup could be imlemented in.
> >
> > Could you use a similar system wide approach as what we discussed
> > previous wrt hardware offload? Use listified only if (forwarding is enabled
> > and no device is registered that implements h/w segmentation offload) or
> > any path requires xfrm transformation (?).
>
> The xfrm transformation has to happen for the segments. So if we need to
> do xfrm transformation in software, we need to do segmentation in
> software too. I think that just forwarding is enabled and the presence
> of a device that can do hardware segmentation offload is not a good
> indicator. The more devices support hardware segmentation offload
> the more likely is it that xfrm take a suboptimal path.

That's why I suggested OR any path requires xfrm.

> We have to do a route lookup anyway, why not just do it early
> in case forwarding is enabled?

But actually, yes, that's true, so fine, too.