During the review of Tom Tucker's server RPC/RDMA transport patchset, 
we receive a request to simplify the RPC/RDMA client and server build 
configuration.

To simplify the configuration, we propose to make XPRT_RDMA a hidden 
config option that continues to depend on SUNRPC and INFINIBAND. The 
value of XPRT_RDMA will be

 - N if either SUNRPC or INFINIBAND are N
 - M if both SUNRPC and INFINIBAND are on (M or Y) and at least one is M
 - Y if both SUNRPC and INFINIBAND are Y

In the next server RPC/RDMA transport patchset, we will group all the 
RPC/RDMA related files in net/sunrpc/xprtrdma and update the 
net/sunrpc/xprtrdma/Makefile to build both the client and server 
RPC/RDMA support using this config option.

Signed-off-by: James Lentini <jlentini@netapp.com>

 Kconfig |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1782,12 +1782,9 @@
 	tristate
 
 config SUNRPC_XPRT_RDMA
-	tristate "RDMA transport for sunrpc (EXPERIMENTAL)"
+	tristate
 	depends on SUNRPC && INFINIBAND && EXPERIMENTAL
-	default m
-	help
-	  Adds a client RPC transport for supporting kernel NFS over RDMA
-	  mounts, including Infiniband and iWARP. Experimental.
+	default SUNRPC && INFINIBAND
 
 config SUNRPC_BIND34
 	bool "Support for rpcbind versions 3 & 4 (EXPERIMENTAL)"
-

[ message continues ]

That's a step in the right direction, IMO.

SUNRPC is always enabled (M or Y) if either the NFS client or server  
are requested.  So, is the intent then always to build the RPC RDMA  
transport module if NFS and INFINIBAND are enabled?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com



-

[ message continues ]

Yep, just like the sockets transport. Of course, the transport won't
be used unless a "mount -o rdma" is done on the client, or the rdma
port node below /proc is admin-configured on the server.

Tom.
-

[ message continues ]