> On Sep 6, 2017, at 3:39 PM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Sep 06, 2017 at 02:33:50PM -0400, Chuck Lever wrote: > >> B. Force RPC completion to wait for Send completion, which >> would allow the post-v4.6 scatter-gather code to work >> safely. This would need some guarantee that Sends will >> always complete in a short period. > > Why is waiting for the send completion so fundamentally different from > waiting for the remote RPC reply? > > I would say that 99% of time the send completion and RPC reply > completion will occure approximately concurrently. > > eg It is quite likely the RPC reply SEND carries an embeded ack > for the requesting SEND.. Depends on implementation. Average RTT on IB is 3-5 usecs. Average RPC RTT is about an order of magnitude more. Typically the Send is ACK'd more quickly than the RPC Reply can be sent. But I get your point: the normal case isn't a problem. The problematic case arises when the Send is not able to complete because the NFS server is not reachable. User starts pounding on ^C, RPC can't complete because Send won't complete, control doesn't return to user. The Send Queue is blocked in that case anyway. That should result in the sendctx queue becoming empty, so that RPCs can't even post another Send, and we avoid the problem with newly issued RPCs. We really do prefer the mechanics of the transport to be detached from the ability of the RPC client and above to respond to user signals, IMO. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
