On Fri, May 1, 2015 at 1:37 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Fri, May 01, 2015 at 01:28:12PM -0400, Trond Myklebust wrote: >> 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. > > Either variant will allow accepting more than one backchannel > request at the RPC layer, that's the whole point. With the simple > patch I posted it will accept a 2nd one, with dynamic allocation > the number would be potentially unbound. If you do it wrong, yes. The point is if you do the allocation as part of the send process, then you prevent unbounded growth. > But given that the NFS client already enforces the slot limit > properly in validate_seqid, and even returns the proper nfs error > for this case I don't really see what enforcing it at a lower level > we we can't even report proper errors buys us. It buys us better congestion control. We don't even need to process the request. 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
