linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "chuck.lever@oracle.com" <chuck.lever@oracle.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] SUNRPC: xprt_load_transport() needs to support the netid "rdma6"
Date: Mon, 9 Nov 2020 22:06:18 +0000	[thread overview]
Message-ID: <f5f3d846dc339fa9b79533235cb7971dd5c8a71d.camel@hammerspace.com> (raw)
In-Reply-To: <1BBDFE45-EFF6-4997-A6C1-E4BB07863ACB@oracle.com>

On Mon, 2020-11-09 at 16:50 -0500, Chuck Lever wrote:
> 
> 
> > On Nov 9, 2020, at 4:10 PM, trondmy@gmail.com wrote:
> > 
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > 
> > According to RFC5666, the correct netid for an IPv6 addressed RDMA
> > transport is "rdma6", which we've supported as a mount option since
> > Linux-4.7. The problem is when we try to load the module
> > "xprtrdma6",
> > that will fail, since there is no modulealias of that name.
> 
> Trying to wrap my head around this. Who is forming the legacy names
> "xprtrdma6" and "svcrdma6" ?

I don't care about "svcrdma6", because nothing uses that name, AFAICS,
because __write_ports_addxprt() appears to use the "transport name",
whatever that is.

> The module name these days is "rpcrdma". Seems like you should fix
> the code that is trying to load these by the wrong name rather than
> adding more legacy names.

No, I'm not going to do that.

The intention was always that xprt_load_transport() should take the
netid as its argument. Furthermore, it makes no sense for either the
NFS or generic RPC layers to have to figure out how by themselves how
to translate netids into transport module names.

> 
> > Fixes: 181342c5ebe8 ("xprtrdma: Add rdma6 option to support
> > NFS/RDMA IPv6")
> > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > ---
> > net/sunrpc/xprtrdma/module.c | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git a/net/sunrpc/xprtrdma/module.c
> > b/net/sunrpc/xprtrdma/module.c
> > index 620327c01302..fb55983628b4 100644
> > --- a/net/sunrpc/xprtrdma/module.c
> > +++ b/net/sunrpc/xprtrdma/module.c
> > @@ -23,7 +23,9 @@ MODULE_AUTHOR("Open Grid Computing and Network
> > Appliance, Inc.");
> > MODULE_DESCRIPTION("RPC/RDMA Transport");
> > MODULE_LICENSE("Dual BSD/GPL");
> > MODULE_ALIAS("svcrdma");
> > +MODULE_ALIAS("svcrdma6");
> > MODULE_ALIAS("xprtrdma");
> > +MODULE_ALIAS("xprtrdma6");
> > 
> > static void __exit rpc_rdma_cleanup(void)
> > {
> > -- 
> > 2.28.0
> > 
> 
> --
> Chuck Lever
> 
> 
> 

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



      reply	other threads:[~2020-11-09 22:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 21:10 [PATCH v2 0/5] Add RDMA support to the pNFS file+flexfiles data channels trondmy
2020-11-09 21:10 ` [PATCH v2 1/5] SUNRPC: xprt_load_transport() needs to support the netid "rdma6" trondmy
2020-11-09 21:10   ` [PATCH v2 2/5] NFSv4/pNFS: Use connections to a DS that are all of the same protocol family trondmy
2020-11-09 21:10     ` [PATCH v2 3/5] NFSv4/pNFS: Store the transport type in struct nfs4_pnfs_ds_addr trondmy
2020-11-09 21:10       ` [PATCH v2 4/5] pNFS/flexfiles: Fix up layoutstats reporting for non-TCP transports trondmy
2020-11-09 21:10         ` [PATCH v2 5/5] pNFS: Clean up open coded kmemdup_nul() trondmy
2020-11-09 21:50   ` [PATCH v2 1/5] SUNRPC: xprt_load_transport() needs to support the netid "rdma6" Chuck Lever
2020-11-09 22:06     ` Trond Myklebust [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f5f3d846dc339fa9b79533235cb7971dd5c8a71d.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).