From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Paasch Subject: Re: [PATCH] udp: Allow to defer reception until connect() happened Date: Mon, 03 Dec 2018 08:45:01 -0800 Message-ID: <20181203164501.GE3611@MacBook-Pro-19.local> References: <20181129015626.85441-1-cpaasch@apple.com> <20181129224703.GW3611@MacBook-Pro-19.local> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Cc: jri.ietf@gmail.com, netdev , Ian Swett , lhedstrom@apple.com To: Eric Dumazet Return-path: Received: from nwk-aaemail-lapp01.apple.com ([17.151.62.66]:44084 "EHLO nwk-aaemail-lapp01.apple.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726650AbeLCQpM (ORCPT ); Mon, 3 Dec 2018 11:45:12 -0500 Content-disposition: inline In-reply-to: Sender: netdev-owner@vger.kernel.org List-ID: On 29/11/18 - 14:59:36, Eric Dumazet wrote: > On Thu, Nov 29, 2018 at 2:47 PM Christoph Paasch 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.