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

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

Message-id: <20181203164501.GE3611@MacBook-Pro-19.local>
Date:   Mon, 03 Dec 2018 08:45:01 -0800
From:   Christoph Paasch <cpaasch@...le.com>
To:     Eric Dumazet <edumazet@...gle.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 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.

> 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?

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.