On Tue, Jan 12, 2010 at 11:57 PM, Roland Dreier <rdre...@cisco.com> wrote: > > > 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?
The impact of the ib_post_recv() call is small but measurable. I'll publish measurement results soon. > > 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. OK, I will first evaluate which alternatives there are for SCST-SRPT such that it does not rely on initiator-side support for SRP_CRED_REQ. This will not only help with pre-2.6.34 SRP initiators but also with other SRP initiators than the one available in the vanilla Linux kernel (e.g. OFED or WinOF). 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
