On Fri, May 1, 2015 at 1:23 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Apr 30, 2015 at 01:41:02PM -0400, Chuck Lever wrote: >> We discussed this briefly during the Linux NFS town hall meeting. >> I agree using dynamic slot allocation for TCP is fine, and RPC/RDMA >> can use simple overprovisioning. >> >> This way the upper layer (NFSv4.1 client) doesn?t have to be aware of >> limitations in the RPC layer mechanism. >> >> Trond may have an additional concern that I didn?t capture. > > The other option would be to simply overallocate in the transport layer, > as that is the layer which causes the problem to start with. > > That being said, what is the argument for doing any sort of static > allocation here? I'm fine with doing fully dynamic allocation if that > works out fine, but a mixed static / dynamic allocation sounds like a > nightmare. The concern is not so much static vs dynamic. The concern is limiting incoming RPC calls to the number allowed by the NFSv4.1 session. Right now, the static allocation enforces the limit of 1 slot that the client offers to the server (albeit with the race) and so I want any replacement to meet the same requirement. Cheers Trond -- 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
