From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets Date: Wed, 31 Oct 2018 22:08:53 -0700 Message-ID: References: <20181031232635.33750-1-cpaasch@apple.com> <0ce864f0-38b9-59cc-18ea-e071afca347d@gmail.com> <20181101035050.GO80792@MacBook-Pro-19.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, Ian Swett , Leif Hedstrom , Jana Iyengar To: Christoph Paasch Return-path: Received: from mail-pl1-f195.google.com ([209.85.214.195]:38836 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726208AbeKAOKR (ORCPT ); Thu, 1 Nov 2018 10:10:17 -0400 Received: by mail-pl1-f195.google.com with SMTP id p7-v6so8362617plk.5 for ; Wed, 31 Oct 2018 22:08:54 -0700 (PDT) In-Reply-To: <20181101035050.GO80792@MacBook-Pro-19.local> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/31/2018 08:50 PM, Christoph Paasch wrote: > On 31/10/18 - 17:53:22, Eric Dumazet wrote: >> On 10/31/2018 04:26 PM, Christoph Paasch wrote: >>> Implementations of Quic might want to create a separate socket for each >>> Quic-connection by creating a connected UDP-socket. >>> >> >> Nice proposal, but I doubt a QUIC server can afford having one UDP socket per connection ? >> >> It would add a huge overhead in term of memory usage in the kernel, >> and lots of epoll events to manage (say a QUIC server with one million flows, receiving >> very few packets per second per flow) >> >> Maybe you could elaborate on the need of having one UDP socket per connection. > > I let Leif chime in on that as the ask came from him. Leif & his team are > implementing Quic in the Apache Traffic Server. > > > One advantage I can see is that it would allow to benefit from fq_pacing as > one could set sk_pacing_rate simply on the socket. That way there is no need > to implement the pacing in the user-space anymore. Our plan is to use EDT model for UDP packets, so that we can still use one (not connected) UDP socket per cpu/thread. We added in linux-4.20 the EDT model for TCP, and I intend to add the remaining part for sch_fq for 4.21. UDP can use an ancillary message (SCM_TXTIME) to attach to the skb (which can be a GSO btw) a tstamp, and pacing will happen just fine.