netdev - Re: [PATCH net-next RFC 0/8] udp and configurable gro

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-LHKr4bWd7uHLxRiYb=rjsJbptQAae_RDxtpRT+Z2-=CQ@mail.gmail.com>
Date:   Fri, 5 Oct 2018 10:41:47 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        steffen.klassert@...unet.com, David Miller <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next RFC 0/8] udp and configurable gro

On Fri, Oct 5, 2018 at 9:53 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> Hi all,
>
> On Fri, 2018-09-14 at 13:59 -0400, Willem de Bruijn wrote:
> > This is a *very rough* draft. Mainly for discussion while we also
> > look at another partially overlapping approach [1].
>
> I'm wondering how we go on from this ? I'm fine with either approaches.

Let me send the udp gro static_key patch. Then we don't need
the enable udp on demand logic (patch 2/4).

Your implementation of GRO is more fleshed out (patch 3/4) than
my quick hack. My only request would be to use a separate
UDP_GRO socket option instead of adding this to the existing
UDP_SEGMENT.

Sounds good?

> Also, I'm interested in [try to] enable GRO/GSO batching in the
> forwarding path, as you outlined initially in the GSO series
> submission. That should cover Steffen use-case, too, right?

Great. Indeed. Though there is some unresolved discussion on
one large gso skb vs frag list. There has been various concerns
around the use of frag lists for GSO in the past, and it does not
match h/w offload. So I think the answer would be the first unless
the second proves considerably faster (in which case it could also
be added later as optimization).