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