On (02/21/18 19:39), Willem de Bruijn wrote:
> >> By the way, the put_cmsg is unconditional even if the caller did
> >> not supply msg_control. So it is basically no longer safe to ever
> >> call read, recv or recvfrom on a socket if zerocopy notifications
> >> are outstanding.
> >
> > Wait, I thou
On Wed, Feb 21, 2018 at 7:26 PM, Sowmini Varadhan
wrote:
> On (02/21/18 18:45), Willem de Bruijn wrote:
>>
>> I do mean returning 0 instead of -EAGAIN if control data is ready.
>> Something like
>>
>> @@ -611,7 +611,8 @@ int rds_recvmsg(struct socket *sock, struct msghdr
>> *msg, size_t size,
>>
>
On (02/21/18 18:45), Willem de Bruijn wrote:
>
> I do mean returning 0 instead of -EAGAIN if control data is ready.
> Something like
>
> @@ -611,7 +611,8 @@ int rds_recvmsg(struct socket *sock, struct msghdr
> *msg, size_t size,
>
> if (!rds_next_incoming(rs, &inc)) {
>
>> Okay. If callers must already handle 0 as a valid return code, then
>> it is fine to add another case that does this.
>>
>> The extra branch in the hot path is still rather unfortunately. Could
>> this be integrated in the existing if (nonblock) branch below?
>
> that's where I first started. it
On (02/21/18 17:50), Willem de Bruijn wrote:
>
> In the common case no more than one notification will be outstanding,
> but with a fixed number of notifications per packet, in edge cases this
> list may be long.
:
> Socket functions block if sk_err is non-zero. See for instance
> tcp_sendmsg_l
On Wed, Feb 21, 2018 at 5:14 PM, Sowmini Varadhan
wrote:
> On (02/21/18 16:54), Willem de Bruijn wrote:
>>
>> I'd put this optimization behind a socket option.
>
> Yes, that thought occurred to me as well- I think RDS applications
> are unlikely to use the error_queue path because, as I mentioned
On (02/21/18 16:54), Willem de Bruijn wrote:
>
> I'd put this optimization behind a socket option.
Yes, that thought occurred to me as well- I think RDS applications
are unlikely to use the error_queue path because, as I mentioned
before, these are heavily request-response based, so you're
going
On Wed, Feb 21, 2018 at 3:19 PM, Sowmini Varadhan
wrote:
> This commit is an optimization that builds on top of commit 01883eda72bd
> ("rds: support for zcopy completion notification") for PF_RDS sockets.
>
> Cookies associated with zerocopy completion are passed up on the POLLIN
> channel, piggyb
On 2/21/2018 12:19 PM, Sowmini Varadhan wrote:
This commit is an optimization that builds on top of commit 01883eda72bd
("rds: support for zcopy completion notification") for PF_RDS sockets.
Cookies associated with zerocopy completion are passed up on the POLLIN
channel, piggybacked with data wh
This commit is an optimization that builds on top of commit 01883eda72bd
("rds: support for zcopy completion notification") for PF_RDS sockets.
Cookies associated with zerocopy completion are passed up on the POLLIN
channel, piggybacked with data whereever possible. Such cookies are passed
up as a
10 matches
Mail list logo