netdev - Re: [PATCH] udp: Allow to defer reception until connect() happened

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: <CANn89iJvUYQANHGxms9+sobQ0qfnm1VRNPYubOPno8qRpBoJ9g@mail.gmail.com>
Date:   Mon, 3 Dec 2018 08:50:48 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Christoph Paasch <cpaasch@...le.com>
Cc:     jri.ietf@...il.com, netdev <netdev@...r.kernel.org>,
        Ian Swett <ianswett@...gle.com>, lhedstrom@...le.com
Subject: Re: [PATCH] udp: Allow to defer reception until connect() happened

On Mon, Dec 3, 2018 at 8:45 AM Christoph Paasch <cpaasch@...le.com> wrote:
>
> On 29/11/18 - 14:59:36, Eric Dumazet wrote:
> > On Thu, Nov 29, 2018 at 2:47 PM Christoph Paasch <cpaasch@...le.com> wrote:
> >
> > > Indeed, the UDP-stack is not fully 4-tuple ready.
> > >
> > >
> > > What are your thoughts on getting it there?
> >
> > This would request an additional lookup, and heavy duty servers using
> > non connected sockets
> > would pay the price for an extra lookup for each incoming packets.
>
> Indeed.
>
>
> But I'm sure we can do it such that those servers don't pay a cost.
>
> E.g., with a jump-label that would only be set when one does a "wait-for-connect"
> and only these sockets end up in that 4-tuple hash-table.

That will work only for benchmarks.
Typical servers have a variety of concurrent tasks.

jump labels are kind of doomed with network namespaces,
and we cant really enable/disable them from a non privileged application,
since this slows down the whole machine.

>
> > DNS servers and QUIC servers would not like that, since they have better use
> > of a single (unconnected) UDP socket per cpu/thread.
>
> I'm actually wondering, how are you doing Quic connection migration when
> having a single unconnected UDP socket per CPU? That would involve quite
> some cross-CPU communication, no?

Maybe a small percentage of packets do need this, so we do not care.

>
> Except if something else is steering the different UDP-flows that belong to the
> same Quic connection to the right CPU...
>
>
> Christoph
>
>
>
> >
> >
> > >
> > > Should be doable by simply using a similar approach as TCP, no? Any caveats
> > > you see with that?
> > >
> > > Then, when one sets the "wait-for-connect"-flag we would add the socket to
> > > the hash-table only at connect()-time also addressing the cache-line miss
> > > you mentioned above.
> >
> > Sure.