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-K3vAEepu8Ri4tYrJ7+Hw7rYWKoe7Y8QRzOovcDZDqu+A@mail.gmail.com>
Date:   Fri, 5 Oct 2018 11:45:57 -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 11:30 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> Hi,
>
> Thank you for the prompt reply!
>

Not at all. Thanks for moving this forward :)

> On Fri, 2018-10-05 at 10:41 -0400, Willem de Bruijn wrote:
> > 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.
>
> Would love that. We need to care of key decr, too (and possibly don't
> be fooled by encap_rcv() users).

I just sent  http://patchwork.ozlabs.org/patch/979525/

Right now all users are those that call setup_udp_tunnel_sock
to register encap_rcv.

If accepted, I'll add a separate patch to decrement the key. That's
probably in udp_tunnel_sock_release, but I need to take a closer
look.

> > Then we don't need the enable udp on demand logic (patch 2/4).
>
> ok.
>
> > 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?
>
> Indeed!
> I need also to add a cmsg to expose to the user the skb gro_size, and
> some test cases. Locally I'm [ab-]using the GRO functionality
> introduced recently on veth to test the code in a namespace pair
> (attaching a dummy XDP program to the RX-side veth). I'm not sure if
> that could fit a selftest.

Very nice. Yes, veth only implements napi in xdp mode.

>
> > > 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).
>
> Agreed.
>
> Let's try the first step first ;)
>
> Final but relevant note: I'll try my best to avoid delaying this, but
> lately I tend to be pre-empted by other tasks, it's difficult for me to
> assure a deadline here.
>
> Cheers,
>
> Paolo
>