Re: [PATCH 09/10] SUNRPC: Change TCP socket space reservation

[Fields Bruce <bfields@fieldses.org>]

On Wed, Jul 06, 2016 at 08:11:53PM +0000, Trond Myklebust wrote:
> 
> > On Jul 6, 2016, at 15:53, J. Bruce Fields <bfields@fieldses.org>
> > 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.