On Wed, Jul 06, 2016 at 08:11:53PM +0000, Trond Myklebust wrote: > > > On Jul 6, 2016, at 15:53, J. Bruce Fields <bfields@xxxxxxxxxxxx> > > wrote: > > > > On Fri, Jun 24, 2016 at 10:55:51AM -0400, Trond Myklebust wrote: > >> Instead of trying (and failing) to predict how much writeable > >> socket space will be available to the RPC call, just fall back to > >> the simple model of deferring processing until the socket is > >> uncongested. > >> > >> If a limit is neeeded, then set the hard per-connection limit. > > > > I was hoping this would be an opportunity to get rid of even more > > code, but there's still the udp case. Do we actually need that? > > > > I wasn’t really too concerned about UDP; I consider it to be legacy > code. Sure, but by the same token maybe it's not worth carrying the extra code for a udp-only optimization; quick untested diff looks like: fs/nfsd/nfs3proc.c | 1 - fs/nfsd/nfs4state.c | 1 - fs/nfsd/nfs4xdr.c | 1 - fs/nfsd/nfsproc.c | 1 - include/linux/sunrpc/svc.h | 16 ---------------- include/linux/sunrpc/svc_xprt.h | 1 - net/sunrpc/svc.c | 6 ------ net/sunrpc/svc_xprt.c | 37 ------------------------------------- net/sunrpc/svcsock.c | 13 +------------ 9 files changed, 1 insertion(+), 76 deletions(-) > That said, I’d argue the existing system make a little more sense in > the case of UDP as you don’t have any equivalent of the TCP window > size. That means the socket buffer sizes are predictable, and so are > more easily modelled as a pipeline. OK, could be. --b. -- 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
