On 5/20/2014 1:34 PM, Or Gerlitz wrote:
On 19/05/2014 17:44, Sagi Grimberg wrote:
There are 4 RDMA_CM events that all basically mean that
the user should teardown the IB connection:
- DISCONNECTED
- ADDR_CHANGE
- DEVICE_REMOVAL
- TIMEWAIT_EXIT
Only in DISCONNECTED/ADDR_CHANGE it makes sense to call
rdma_disconnect (send DREQ/DREP to our initiator). So we keep the
same teardown handler for all of them but only indicate calling
rdma_disconnect for the relevant events.
Note that rdma_disconnect moves the RC QP used by isert into the error
state and this would cause the HW to flush the the currently posted
receive buffers. Depending on isert implementation, we need to see if
avoiding the flushes would eventually (...) lead to resources (e.g
memory, IOMMU entries, etc) leaks. For example if the IB driver module
is probed out you will get the device removal event, and on that case
why not put the QP into error and get the flushes?
When getting a TIMEWAIT_EXIT the QP should already be in error state and
probably flushes were consumed.
For DEVICE_REMOVAL I was sure this was the case as well, but I don't see
that in the cma code - should we call rdma_disconnect in DEVICE_REMOVAL
as well?
also if the target sent REP (e.g rdma_accept was called) and the
initiator didn't send RTU, @ some point isert will get the unreachable
or connect error events, need to clean there too.
Yes, I did leave these out for this patch as I didn't have capacity to
test it all.
But most definitely, CONNECT_ERROR should be properly handled.
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
