> On Dec 5, 2017, at 10:36 AM, Anna Schumaker <anna.schumaker@xxxxxxxxxx> wrote: > > Hi Chuck, > > On 12/04/2017 02:13 PM, Chuck Lever wrote: >> Helen Chao <helen.chao@xxxxxxxxxx> noticed that when a user >> traverses a referral on an NFS/RDMA mount, the resulting submount >> always uses TCP. >> >> This behavior does not match the vers= setting when traversing >> a referral (vers=4.1 is preserved). It also does not match the >> behavior of crossing from the pseudofs into a real filesystem >> (proto=rdma is preserved in that case). >> >> The Linux NFS client does not currently support the >> fs_locations_info attribute. The situation is similar for all >> NFSv4 servers I know of. Therefore until the community has broad >> support for fs_locations_info, when following a referral: >> >> - First try to connect with RPC-over-RDMA. This will fail quickly >> if the client has no RDMA-capable interfaces. >> >> - If connecting with RPC-over-RDMA fails, or the RPC-over-RDMA >> transport is not available, use TCP. > > Won't this have the opposite problem if the client and server have RDMA interfaces, but are currently mounted over TCP instead? The new behavior will prefer NFS/RDMA, yes. However, typically the referral will contain a hostname or IP address that either supports both or only TCP. In the former case, the client will now choose RDMA instead of TCP, and in the latter, it should always use TCP. IOW the referral has to point to a server IP address that can do either transport before the client can choose RDMA. > Anna > >> >> Reported-by: Helen Chao <helen.chao@xxxxxxxxxx> >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> >> --- >> fs/nfs/nfs4client.c | 23 ++++++++++++++++++++--- >> fs/nfs/nfs4namespace.c | 2 -- >> 2 files changed, 20 insertions(+), 5 deletions(-) >> >> diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c >> index 12bbab0..a3d5592 100644 >> --- a/fs/nfs/nfs4client.c >> +++ b/fs/nfs/nfs4client.c >> @@ -1114,19 +1114,36 @@ struct nfs_server *nfs4_create_referral_server(struct nfs_clone_mount *data, >> /* Initialise the client representation from the parent server */ >> nfs_server_copy_userdata(server, parent_server); >> >> - /* Get a client representation. >> - * Note: NFSv4 always uses TCP, */ >> + /* Get a client representation */ >> +#ifdef CONFIG_SUNRPC_XPRT_RDMA >> + rpc_set_port(data->addr, NFS_RDMA_PORT); >> error = nfs4_set_client(server, data->hostname, >> data->addr, >> data->addrlen, >> parent_client->cl_ipaddr, >> - rpc_protocol(parent_server->client), >> + XPRT_TRANSPORT_RDMA, >> + parent_server->client->cl_timeout, >> + parent_client->cl_mvops->minor_version, >> + parent_client->cl_net); >> + if (!error) >> + goto init_server; >> +#endif /* CONFIG_SUNRPC_XPRT_RDMA */ >> + >> + rpc_set_port(data->addr, NFS_PORT); >> + error = nfs4_set_client(server, data->hostname, >> + data->addr, >> + data->addrlen, >> + parent_client->cl_ipaddr, >> + XPRT_TRANSPORT_TCP, >> parent_server->client->cl_timeout, >> parent_client->cl_mvops->minor_version, >> parent_client->cl_net); >> if (error < 0) >> goto error; >> >> +#ifdef CONFIG_SUNRPC_XPRT_RDMA >> +init_server: >> +#endif >> error = nfs_init_server_rpcclient(server, parent_server->client->cl_timeout, data->authflavor); >> if (error < 0) >> goto error; >> diff --git a/fs/nfs/nfs4namespace.c b/fs/nfs/nfs4namespace.c >> index 8c3f327..24f06dc 100644 >> --- a/fs/nfs/nfs4namespace.c >> +++ b/fs/nfs/nfs4namespace.c >> @@ -270,8 +270,6 @@ static struct vfsmount *try_location(struct nfs_clone_mount *mountdata, >> if (mountdata->addrlen == 0) >> continue; >> >> - rpc_set_port(mountdata->addr, NFS_PORT); >> - >> memcpy(page2, buf->data, buf->len); >> page2[buf->len] = '\0'; >> mountdata->hostname = page2; >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Chuck Lever -- 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
