From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: [PATCH] IB/srp: Fix initiator lockup Date: Tue, 12 Jan 2010 14:57:35 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: (Bart Van Assche's message of "Tue, 12 Jan 2010 18:23:22 +0100") Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Bart Van Assche Cc: OFED mailing list , Chris Worley List-Id: linux-rdma@vger.kernel.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