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? 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.
Or. Or. Or. -- 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
