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
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 <firstname.lastname@example.org>
Kconfig | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
@@ -1782,12 +1782,9 @@
- tristate "RDMA transport for sunrpc (EXPERIMENTAL)"
depends on SUNRPC && INFINIBAND && EXPERIMENTAL
- default m
- Adds a client RPC transport for supporting kernel NFS over RDMA
- mounts, including Infiniband and iWARP. Experimental.
+ default SUNRPC && INFINIBAND
bool "Support for rpcbind versions 3 & 4 (EXPERIMENTAL)"
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?
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.