Re: [PATCH] IB/srp: Fix initiator lockup

[Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>]

 > 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html