On Thu, Dec 31, 2015 at 09:57:58AM +0100, Bart Van Assche wrote:
> Since patch "IB/srpt: chain RDMA READ/WRITE requests" there are
> two loops that process the command wait list. ch->cmd_wait_list
> is accessed without locking which means that all code that
> accesses this list must be serialized.
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
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
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
Since patch "IB/srpt: chain RDMA READ/WRITE requests" there are
two loops that process the command wait list. ch->cmd_wait_list
is accessed without locking which means that all code that
accesses this list must be serialized. Since processing of the
RTU event happens from another context than IB
