On Thu, Jan 18, 2018 at 6:20 PM, Sowmini Varadhan
wrote:
> On (01/18/18 18:09), Willem de Bruijn wrote:
>> If that is true in general for PF_RDS, then it is a reasonable approach.
>> How about treating it as a (follow-on) optimization path. Opportunistic
>> piggybacking of notifications on data re
On (01/18/18 18:09), Willem de Bruijn wrote:
> If that is true in general for PF_RDS, then it is a reasonable approach.
> How about treating it as a (follow-on) optimization path. Opportunistic
> piggybacking of notifications on data reads is more widely applicable.
sounds good.
> > that's simila
On Thu, Jan 18, 2018 at 6:03 PM, Sowmini Varadhan
wrote:
> On (01/18/18 17:54), Willem de Bruijn wrote:
>> > 2. If we have the option of passing completion-notification up as ancillary
>> >data on the pollin/recvmsg channel itself (instead of MSG_ERRQUEUE)
>>
>> This assumes a somewhat symmetr
On (01/18/18 17:54), Willem de Bruijn wrote:
> > 2. If we have the option of passing completion-notification up as ancillary
> >data on the pollin/recvmsg channel itself (instead of MSG_ERRQUEUE)
>
> This assumes a somewhat symmetric workload, where there are enough recv
> calls to reap the no
On Thu, Jan 18, 2018 at 12:12 PM, Sowmini Varadhan
wrote:
> On (01/18/18 08:53), Eric Dumazet wrote:
>>
>> The thing is : MSG_PEEK 'support' will also need SO_PEEK_OFF support.
>
> sure, I'll drop the MSG_PEEK idea (which I wasnt very thrilled
> about anyway)
>
>> So lets properly design things, a
On (01/18/18 08:53), Eric Dumazet wrote:
>
> The thing is : MSG_PEEK 'support' will also need SO_PEEK_OFF support.
sure, I'll drop the MSG_PEEK idea (which I wasnt very thrilled
about anyway)
> So lets properly design things, and not re-use legacy stuff that is
> proven to be not multi-thread re
On Thu, 2018-01-18 at 11:10 -0500, Sowmini Varadhan wrote:
> On (01/18/18 07:54), Eric Dumazet wrote:
> >
> > Some applications out there would break horribly, trust me.
> >
>
> so I'm not particularly attached to that solution, and I appreciate
> the wisdom (and the NACK), but lets try to find
On (01/18/18 07:54), Eric Dumazet wrote:
>
> Some applications out there would break horribly, trust me.
>
so I'm not particularly attached to that solution, and I appreciate
the wisdom (and the NACK), but lets try to find a useful alternative
The current zcopy completion notification mechanism
On Wed, 2018-01-17 at 04:19 -0800, Sowmini Varadhan wrote:
> Allow the application the ability to use MSG_PEEK with sk_error_queue
> so that it can peek and re-read message in cases where MSG_TRUNC
> may be encountered.
>
> Signed-off-by: Sowmini Varadhan
Lets not add buggy feature that only fu
On Thu, 2018-01-18 at 06:02 -0500, Sowmini Varadhan wrote:
> On (01/17/18 18:50), Willem de Bruijn wrote:
> >
> > This can cause reordering with parallel readers. Can we avoid the need
> > for peeking? It also caused a slew of subtle bugs previously.
>
> Yes, I did notice the potential for re-ord
On (01/17/18 18:50), Willem de Bruijn wrote:
>
> This can cause reordering with parallel readers. Can we avoid the need
> for peeking? It also caused a slew of subtle bugs previously.
Yes, I did notice the potential for re-ordering when writing the patch..
but these are not actuallly messages fro
On Wed, Jan 17, 2018 at 7:19 AM, Sowmini Varadhan
wrote:
> Allow the application the ability to use MSG_PEEK with sk_error_queue
> so that it can peek and re-read message in cases where MSG_TRUNC
> may be encountered.
>
> Signed-off-by: Sowmini Varadhan
> int sock_recv_errqueue(struct sock *sk,
Allow the application the ability to use MSG_PEEK with sk_error_queue
so that it can peek and re-read message in cases where MSG_TRUNC
may be encountered.
Signed-off-by: Sowmini Varadhan
---
drivers/net/tun.c |2 +-
include/net/sock.h |2 +-
net/core/sock.c|7 +--
13 matches
Mail list logo
