On Wed, Jan 13, 2010 at 12:24 AM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > [ ... ] > > Also, I couldn't tell for sure from a cursory examination of the > patch, but the initiator must be designed to not stall processing the > RQ dependent on the SQ or the credit level, when using a credit scheme > like this. Or you will deadlock. > > For instance it isn't clear to me how the control flow around > srp_process_cred_req is ment to work - it tries to send a reply, but > if it can't due to srp_get_txp_iu failing it just gives up forever?
For a standards-conforming SRP target, srp_get_txp_iu() will never fail. A quote from section 5.5.2 of the SRP r16a document: SRP target ports shall limit themselves to one outstanding SRP request (see table 7) per RDMA channel. Upon sending an SRP request, an SRP target port shall not send another SRP request on the same RDMA channel until after it receives the SRP response (see table 8) for the previous SRP request. 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
