SRP fail-over faster
Subsystems (2)
PATCH 1/4 SRP fail-over faster
Recreating qp, cq at reconnect instead of re-use them. We need this so that we don't have to wait on disconnect connection
--- drivers/infiniband/ulp/srp/ib_srp.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/infiniband/ulp/srp/ib_srp.c +11 -11
@@ -537,10 +537,10 @@ static void srp_reset_req(struct srp_tarstatic int srp_reconnect_target (struct srp_target_port *target) { -struct ib_qp_attr qp_attr;struct srp_request *req, *tmp; -struct ib_wc wc;int ret; +struct ib_cq *old_cq; +struct ib_qp *old_qp;spin_lock_irq (target->scsi_host->host_lock);if (target->state !=SRP_TARGET_LIVE ) {
@@ -559,17 +559,17 @@ static int srp_reconnect_target(struct sif (ret) goto err; - qp_attr.qp_state =IB_QPS_RESET ; - ret =ib_modify_qp (target->qp, &qp_attr,IB_QP_STATE ); -if (ret) - goto err; - - ret =srp_init_qp (target, target->qp); -if (ret) + old_qp = target->qp; + old_cq = target->cq; + ret =srp_create_target_ib (target); +if (ret) { + target->qp = old_qp; + target->cq = old_cq; goto err; + } -while (ib_poll_cq (target->cq,1 , &wc) >0 ) - ;/* nothing */ +ib_destroy_qp (old_qp); +ib_destroy_cq (old_cq);spin_lock_irq (target->scsi_host->host_lock);list_for_each_entry_safe (req, tmp, &target->req_queue, list)
A message that is not in the archive (sent off-list or not yet received): 4AD3B433.7040803-VPRAkNaXOzVWk0Htik3J/[email protected]
One meta comment: when sending a series of 4 patches, please choose a descriptive subject for each one. We don't want the same headline in the kernel log for all 4 patches.
drivers/infiniband/ulp/srp/ib_srp.c static int srp_reconnect_target(struct s · line 564
Quoted 10 lines
drivers/infiniband/ulp/srp/ib_srp.c +3
-7- qp_attr.qp_state =IB_QPS_RESET ; - ret =ib_modify_qp (target->qp, &qp_attr,IB_QP_STATE ); -if (ret) - goto err; - - ret =srp_init_qp (target, target->qp); -if (ret) + old_qp = target->qp; + old_cq = target->cq; + ret =srp_create_target_ib (target);
I don't understand why this is any faster? Is creating a new QP really any different from modifying an old QP to reset state?
--
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 5 lines · Roland Dreier
One meta comment: when sending a series of 4 patches, please choose a descriptive subject for each one. We don't want the same headline in the kernel log for all 4 patches.
I'll remember next time
Quoted 5 lines
Quoted 5 lines
drivers/infiniband/ulp/srp/ib_srp.c +0
-5- qp_attr.qp_state =IB_QPS_RESET ; - ret =ib_modify_qp (target->qp, &qp_attr,IB_QP_STATE ); -if (ret) - goto err; -
Quoted 9 lines
drivers/infiniband/ulp/srp/ib_srp.c static int srp_reconnect_target(struct s · line 564
Quoted 5 lines
drivers/infiniband/ulp/srp/ib_srp.c +3
-2- ret =srp_init_qp (target, target->qp); -if (ret) + old_qp = target->qp; + old_cq = target->cq; + ret =srp_create_target_ib (target);I don't understand why this is any faster? Is creating a new QP really any different from modifying an old QP to reset state?
It is not; it is needed for patch 2/4 disconnect without wait and it is faster that way --
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