IB/srp: adjust can_queue
Subsystems (2)
PATCH v3 3/4 IB/srp: adjust can_queue
The SRP (draft) standard specifies that an SRP initiator must never queue more than (SRP request limit) - 1 unanswered SRP_CMD information units. This patch makes sure that the SCSI mid-layer never tries to queue more than (SRP request limit) - 1 SCSI commands to ib_srp. This improves performance for targets whose request limit is less than or equal to SRP_SQ_REQ_SIZE (63) by reducing the number of BUSY responses reported by ib_srp to the SCSI mid-layer.
--- drivers/infiniband/ulp/srp/ib_srp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/infiniband/ulp/srp/ib_srp.c +1 -1
@@ -1436,7 +1436,7 @@ static int srp_cm_handler(struct ib_cm_id *cm_id, struct ib_cm_event *event) target->max_ti_iu_len =be32_to_cpu (rsp->max_ti_iu_len); target->req_lim =be32_to_cpu (rsp->req_lim_delta); - target->scsi_host->can_queue =min (target->req_lim, + target->scsi_host->can_queue =min (target->req_lim -1 , target->scsi_host->can_queue); }else { shost_printk(KERN_WARNING, target->scsi_host,
Signature · 5 lines
1.6.4.2 -- 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 6 lines · Bart Van Assche
The SRP (draft) standard specifies that an SRP initiator must never queue more than (SRP request limit) - 1 unanswered
SRP_CMDinformation units. This patch makes sure that the SCSI mid-layer never tries to queue more than (SRP request limit) - 1 SCSI commands toib_srp. This improves performance for targets whose request limit is less than or equal toSRP_SQ_REQ_SIZE(63) by reducing the number of BUSY responses reported byib_srpto the SCSI mid-layer.
Actually, the standard states we can never send more than REQUEST LIMIT requests. But we reserve 1 request for sending task management requests, so that's why we need to tell the mid-layer to not send us more than req_lim - 1 commands.
Dave
--
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): 1280849064.20446.46.camel-FqX9LgGZnHWDB2HL1qBt2PIbXMQ5te18@public.gmane.org
Quoted 8 lines · David Dillow
Quoted 6 lines · Bart Van Assche
The SRP (draft) standard specifies that an SRP initiator must never queue more than (SRP request limit) - 1 unanswered
SRP_CMDinformation units. This patch makes sure that the SCSI mid-layer never tries to queue more than (SRP request limit) - 1 SCSI commands toib_srp. This improves performance for targets whose request limit is less than or equal toSRP_SQ_REQ_SIZE(63) by reducing the number of BUSY responses reported byib_srpto the SCSI mid-layer.
Quoted 4 lines
Actually, the standard states we can never send more than REQUEST LIMIT requests. But we reserve 1 request for sending task management requests, so that's why we need to tell the mid-layer to not send us more than
req_lim- 1 commands.
The SRP spec says the following about the request limit and management commands:
c) An SRP initiator port may send an SRP request on an RDMA channel when the value of the RDMA
channel’s Request Limit variable is greater than zero. An SRP initiator port shall not send an SRP
request on any RDMA channel whose Request Limit variable has a value less than or equal to zero; the
results of doing so are vendor-specific. To ensure that task management requests may be sent, an SRP
initiator port may choose to send commands only when the value of the Request Limit variable is greater
than one;
So reserving one queue element for management commands is not a requirement but a recommendation. I agree that the patch description has to be updated.
Bart.
--
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