From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Paasch <cpaasch@apple.com>
Cc: netdev@vger.kernel.org, Ian Swett <ianswett@google.com>,
Leif Hedstrom <lhedstrom@apple.com>,
Jana Iyengar <jri.ietf@gmail.com>
Subject: Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets
Date: Wed, 31 Oct 2018 22:08:53 -0700 [thread overview]
Message-ID: <d04b03fd-7a1a-2f0e-6031-f13ccc6b6b48@gmail.com> (raw)
In-Reply-To: <20181101035050.GO80792@MacBook-Pro-19.local>
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.
next prev parent reply other threads:[~2018-11-01 14:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 23:26 [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets Christoph Paasch
2018-10-31 23:26 ` [RFC 1/2] net: Add new socket-option SO_DELAYED_BIND Christoph Paasch
2018-10-31 23:26 ` [RFC 2/2] udp: Support SO_DELAYED_BIND Christoph Paasch
2018-11-01 0:53 ` [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets Eric Dumazet
2018-11-01 3:50 ` Christoph Paasch
2018-11-01 5:04 ` Eric Dumazet
2018-11-01 5:07 ` Christoph Paasch
2018-11-01 5:08 ` Eric Dumazet [this message]
2018-11-01 5:17 ` Eric Dumazet
2018-11-01 17:58 ` Leif Hedstrom
2018-11-01 18:21 ` Eric Dumazet
2018-11-01 21:51 ` Willem de Bruijn
2018-11-01 22:11 ` Christoph Paasch
[not found] ` <CAKcm_gNZqgRGRj2J5yJDsavHsoaeXtozrbGp+TmAj_DRsCUOLQ@mail.gmail.com>
[not found] ` <CACpbDccs6WmLCknpu2GLMMBnkHwS4apsr3Z3sAKt4Ch_2HPwgg@mail.gmail.com>
2018-11-04 18:58 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d04b03fd-7a1a-2f0e-6031-f13ccc6b6b48@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=cpaasch@apple.com \
--cc=ianswett@google.com \
--cc=jri.ietf@gmail.com \
--cc=lhedstrom@apple.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.