netdev - Re: [RFC PATCH 2/4] net: enable UDP gro on demand.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAF=yD-+OfMMzP-aX=O2KO+XJy0o0zgRf5LJG3ELNABhf_aUh7w@mail.gmail.com>
Date:   Sun, 16 Sep 2018 14:23:04 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>,
        steffen.klassert@...unet.com
Subject: Re: [RFC PATCH 2/4] net: enable UDP gro on demand.

On Fri, Sep 14, 2018 at 1:16 PM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> On Fri, Sep 14, 2018 at 11:47 AM Paolo Abeni <pabeni@...hat.com> wrote:
> >
> > Currently, the UDP GRO callback is always invoked, regardless of
> > the existence of any actual user (e.g. a UDP tunnel). With retpoline
> > enabled, this causes measurable overhead.
> >
> > This changeset introduces explicit accounting of the sockets requiring
> > UDP GRO and updates the UDP offloads at runtime accordingly, so that
> > the GRO callback is present (and invoked) only when there is at least
> > one socket requiring it.
>
> I have a difference solution both to the UDP socket lookup avoidance
> and configurable GRO in general.
>
> I've been sitting on it for too long. Let me slightly clean it up and
> send it out for discussion sake..

http://patchwork.ozlabs.org/project/netdev/list/?series=65763

That udp gro implementation is clearly less complete than yours in
this patchset. The point I wanted to bring up for discussion is not the
protocol implementation, but the infrastructure for enabling it
conditionally.

Assuming cycle cost is comparable, what do you think of  using the
existing sk offload callbacks to enable this on a per-socket basis?

As for the protocol-wide knob, I do strongly prefer something that can
work for all protocols, not just UDP. I also implemented a version that
atomically swaps the struct ptr instead of the flag based approach I sent
for review. I'm fairly agnostic about that point. One subtle issue is that I
believe we need to keep the gro_complete callbacks enabled, as gro
packets may be queued for completion when gro_receive gets disabled.