SUNRPC: Use a cached RPC client and transport for rpcbind upcalls
authorChuck Lever <chuck.lever@oracle.com>
Thu, 3 Dec 2009 20:58:56 +0000 (15:58 -0500)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Thu, 3 Dec 2009 20:58:56 +0000 (15:58 -0500)
commitc526611dd631b2802b6b0221ffb306c5fa25c86c
tree909f241683fbe848b484cef24a77d716c486d25c
parent5a46211540a83871196489247f57da2bdde58d87
SUNRPC: Use a cached RPC client and transport for rpcbind upcalls

The kernel's rpcbind client creates and deletes an rpc_clnt and its
underlying transport socket for every upcall to the local rpcbind
daemon.

When starting a typical NFS server on IPv4 and IPv6, the NFS service
itself does three upcalls (one per version) times two upcalls (one
per transport) times two upcalls (one per address family), making 12,
plus another one for the initial call to unregister previous NFS
services.  Starting the NLM service adds an additional 13 upcalls,
for similar reasons.

(Currently the NFS service doesn't start IPv6 listeners, but it will
soon enough).

Instead, let's create an rpc_clnt for rpcbind upcalls during the
first local rpcbind query, and cache it.  This saves the overhead of
creating and destroying an rpc_clnt and a socket for every upcall.

The new logic also prevents the kernel from attempting an RPCB_SET or
RPCB_UNSET if it knows from the start that the local portmapper does
not support rpcbind protocol version 4.  This will cut down on the
number of rpcbind upcalls in legacy environments.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
net/sunrpc/rpcb_clnt.c
net/sunrpc/sunrpc_syms.c