On Tue, Aug 3, 2010 at 5:24 PM, David Dillow <d...@thedillows.org> wrote: > On Tue, 2010-08-03 at 16:08 +0200, Bart Van Assche wrote: >> 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. > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
