On 01/03/2016 12:25 PM, Sagi Grimberg wrote:
But now the first I/O(s) could be lost if no other I/O comes in,
right? I suspect that we need to keep this loop to protect against
such corner cases.
It can happen theoretically, but why do we even bother? Why not just
post the recv buffer after we moved in to CH_LIVE? This why we let the
RC transport handle the "Recv-Not-Ready" NAK by retrying?
Making wait list processing in the RTU handler safe would require to
introduce additional locking. Posting receive buffers after the RTU
event has been received would introduce another race condition because
then it can happen that an initiator starts sending data before the
receive buffers have been posted. A possible solution would be to
trigger the receive handler after the RTU event has been received in
such a way that all invocations of the receive handler are still serialized.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
