On 11/04/2018 02:45 AM, Jana Iyengar wrote:
> I think SO_TXTIME solves the most egregious problem I have with using
> sched_fq for QUIC. That's a great help, so thank you!
>
> That said, as Ian says, SO_TXTIME does not allow for the flow isolation
> properties of sched_fq, which would be a ni
On 01/11/18 - 17:51:39, Willem de Bruijn wrote:
> On Wed, Oct 31, 2018 at 7:30 PM Christoph Paasch wrote:
> >
> > Implementations of Quic might want to create a separate socket for each
> > Quic-connection by creating a connected UDP-socket.
> >
> > To achieve that on the server-side, a "master-so
On Wed, Oct 31, 2018 at 7:30 PM Christoph Paasch wrote:
>
> Implementations of Quic might want to create a separate socket for each
> Quic-connection by creating a connected UDP-socket.
>
> To achieve that on the server-side, a "master-socket" needs to wait for
> incoming new connections and then
> On Oct 31, 2018, at 6:53 PM, 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 a
On 11/01/2018 10:58 AM, Leif Hedstrom wrote:
>
>
>> On Oct 31, 2018, at 6:53 PM, 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.
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
On 10/31/2018 10:08 PM, Eric Dumazet wrote:
> 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 us
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 prop
> On Oct 31, 2018, at 10:04 PM, Eric Dumazet wrote:
>
>
>
>> On 10/31/2018 08:50 PM, Christoph Paasch wrote:
>>
>> What we had here is that we wanted to let a server initiate more than 64K
>> connections *while* binding also to a source-IP.
>> With TCP the bind() would then pick a source-po
On 10/31/2018 08:50 PM, Christoph Paasch wrote:
> What we had here is that we wanted to let a server initiate more than 64K
> connections *while* binding also to a source-IP.
> With TCP the bind() would then pick a source-port and we ended up hitting the
> 64K limit. If we could do an atomic "b
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 ove
Implementations of Quic might want to create a separate socket for each
Quic-connection by creating a connected UDP-socket.
To achieve that on the server-side, a "master-socket" needs to wait for
incoming new connections and then creates a new socket that will be a
connected UDP-socket. To create
12 matches
Mail list logo
