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.
And what is the problem with that? The peer HCA will get a RNR_NAK
and retry a pre-configured number of retries (7). The initiator stack
won't feel it at all...
I'd say it's a clean way to go.
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.
We can also do that, it's less trivial though.
--
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
