sorry for the top post. Indeed, I tend to agree that it seems the IB CM maintainer isn't likely to change the flow there. Still we need to see how to bake two patches, one for the initiator and one for the target and push them to stable kernels. Or. ________________________________________ From: Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> Sent: 29 June 2014 12:06 To: Nicholas A. Bellinger; Or Gerlitz Cc: Sagi Grimberg; target-devel@xxxxxxxxxxxxxxx Subject: Re: [PATCH] Target/iser: Fix initiator_depth and responder_resources On 6/27/2014 7:06 AM, Nicholas A. Bellinger wrote: > Hi Or & Sagi, > > On Sun, 2014-06-22 at 10:47 +0300, Or Gerlitz wrote: >> On 19/06/2014 13:54, Sagi Grimberg wrote: >>> The iser target is the RDMA requester and the iser initiator is the >>> RDMA responder. In order to determine the max inflight RDMA READ requests >>> to set on the QP (initiator_depth), it should take the min between the >>> initiator published initiator_depth and the max inflight rdma read >>> requests its local HCA support (max_qp_init_rd_atom). >> Let's hold with this couple of days till we resolve a related issue with >> the IB CM maintainer, we see something there which looks like a related >> bug, whose resolution or non-resolution would influence this piece, I >> posted a note to the maintainer >> http://marc.info/?l=linux-rdma&m=140342303412247&w=2 >> >> > What's the status on this patch..? Should it be included in tomorrow's > -rc3 PULL request, or delayed until the other bit can be addressed..? I don't think that the CM will change it's behavior. AFAICT you can include it. Or? Sagi. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
