> Having separate buffer sets for command receives and response sends > might seem a sensible way to design a target. But calling > ib_post_recv() before sending a response back to the initiator is not > acceptable because this increases communication latency. When a target > uses separate buffer sets, sends back SRP_RSP before responses before > ib_post_recv() is called, and when it processes SRP_CMD requests in > parallel, it still can happen that a sequence of RL - 2 SRP_RSP > responses is sent back to the initiator all with the REQUEST LIMIT > DELTA field set to zero. So even with separate buffer sets there is a > need for SRP_CRED_REQ support in the initiator.
I doubt you could benchmark the overhead of calling ib_post_recv() in the full SRP protocol. Really, I bet it's less than 100 nanoseconds to form the work request and call ib_post_recv(). Maybe I'm wrong but I really expect the overhead of actually doing IO (even to a ramdisk buffer or something) is going to be much higher than posting a receive. Or maybe you did benchmark it and I'm wrong? > I'm surprised by all this opposition against adding SRP_CRED_REQ > support in the initiator, a feature defined in the SRP standard ? As I said I agree we should implement support for SRP_CRED_REQ. However I think it would be better if the SCST target could be made to work reliably with pre-2.6.34 initiators as well. - R. -- 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
