SRP fail-over faster
Subsystems (2)
PATCH 2/4 SRP fail-over faster
Disconnect connection without waiting.
--- drivers/infiniband/ulp/srp/ib_srp.c | 2 -- 1 file changed, 2 deletions(-)
drivers/infiniband/ulp/srp/ib_srp.c +0 -2
@@ -421,7 +421,6 @@ static void srp_disconnect_target(struct PFX "Sending CM DREQ failed\n");return ; } -wait_for_completion (&target->done); }static void srp_remove_work (struct work_struct *work)
@@ -1301,7 +1300,6 @@ static int srp_cm_handler(struct ib_cm_ishost_printk (KERN_ERR , target->scsi_host,PFX "connection closed\n" ); - comp =1 ; target->status =0 ;break ;
A message that is not in the archive (sent off-list or not yet received): 4AD3B443.7040107-VPRAkNaXOzVWk0Htik3J/[email protected]
drivers/infiniband/ulp/srp/ib_srp.c static void srp_disconnect_target(struct · line 424
Quoted 2 lines
drivers/infiniband/ulp/srp/ib_srp.c +0
-1-wait_for_completion (&target->done);
How do you avoid leaking connection on module unload etc? Don't we have to wait for the disconnect to finish somewhere?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Roland Dreier
drivers/infiniband/ulp/srp/ib_srp.c static void srp_disconnect_target(struct · line 424
Quoted 1 line
drivers/infiniband/ulp/srp/ib_srp.c +0
-1-wait_for_completion (&target->done);How do you avoid leaking connection on module unload etc? Don't we have to wait for the disconnect to finish somewhere?
- R.
Are you talking about cm_id?
I think that we wait because we want to reuse cq/qp associate with the connection. On module unload, we destroy cm_id, cq, qp altogether.
-vu
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 4AD62D9D.1020900-VPRAkNaXOzVWk0Htik3J/[email protected]
Quoted 6 lines
Quoted 6 lines
drivers/infiniband/ulp/srp/ib_srp.c static void srp_disconnect_target(struct · line 424
Quoted 2 lines
drivers/infiniband/ulp/srp/ib_srp.c +0
-1-wait_for_completion (&target->done);How do you avoid leaking connection on module unload etc? Don't we have to wait for the disconnect to finish somewhere?
Quoted 6 lines
Quoted 2 lines
- R.
Are you talking about
cm_id?
I think that we wait because we want to reuse cq/qp associate with the connection.
On module unload, we destroycm_id, cq, qp altogether.
OK, I think I understand this piece locally (although if you delete the wait_for_completion() it would probably make more sense to delete the init_completion() just before it as well).
However is it really a correct to reuse a cm_id that is in state timewait to initiate a new connection? That seems pretty fragile to me. --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 12 lines · Roland Dreier
Quoted 11 lines
Quoted 7 lines
Review
Quoted 1 line
(quoted diff) +0
-1- wait_for_completion(&target->done);How do you avoid leaking connection on module unload etc? Don't we have to wait for the disconnect to finish somewhere?
- R.
Are you talking about
cm_id?
I think that we wait because we want to reuse cq/qp associate with the connection.
On module unload, we destroycm_id, cq, qp altogether.
Quoted 7 lines
OK, I think I understand this piece locally (although if you delete the
wait_for_completion()it would probably make more sense to delete theinit_completion()just before it as well).However is it really a correct to reuse a
cm_idthat is in state timewait to initiate a new connection? That seems pretty fragile to me.
Understood. However, we have to wait (1 << max(timeout - 8, 0)) ms; therefore, we need to disconnect without wait --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines · Roland Dreier
Quoted 11 lines
Quoted 7 lines
Review
Quoted 1 line
(quoted diff) +0
-1- wait_for_completion(&target->done);How do you avoid leaking connection on module unload etc? Don't we have to wait for the disconnect to finish somewhere?
- R.
Are you talking about
cm_id?
I think that we wait because we want to reuse cq/qp associate with the connection.
On module unload, we destroycm_id, cq, qp altogether.
Quoted 7 lines
OK, I think I understand this piece locally (although if you delete the
wait_for_completion()it would probably make more sense to delete theinit_completion()just before it as well).However is it really a correct to reuse a
cm_idthat is in state timewait to initiate a new connection? That seems pretty fragile to me.
Here is the updated patch to remove both init_completion() and wait_for_completion()
Disconnect the connection without waiting (1 << max(timeout -8),0) ms
drivers/infiniband/ulp/srp/ib_srp.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-)
drivers/infiniband/ulp/srp/ib_srp.c +0 -3
@@ -415,13 +415,11 @@ static void srp_disconnect_target(struct srp_target_port *target) {/* XXX should send SRP_I_LOGOUT request */ -init_completion (&target->done);if (ib_send_cm_dreq (target->cm_id,NULL ,0 )) {shost_printk (KERN_DEBUG , target->scsi_host,PFX "Sending CM DREQ failed\n" );return ; } -wait_for_completion (&target->done); }static void srp_remove_work (struct work_struct *work)
@@ -1301,7 +1299,6 @@ static int srp_cm_handler(struct ib_cm_id *cm_id, struct ib_cm_event *event)shost_printk (KERN_ERR , target->scsi_host,PFX "connection closed\n" ); - comp =1 ; target->status =0 ;break ;