On Thu, Oct 08, 2020 at 12:21:10PM -0400, Chuck Lever wrote: > > > > On Oct 8, 2020, at 12:08 PM, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > > On Thu, Oct 08, 2020 at 07:08:42PM +0800, Ka-Cheong Poon wrote: > >> Note that namespace does not really play a role in this "rogue" reasoning. > >> The init_net is also a namespace. The "rogue" reasoning means that no > >> kernel module should start a listening RDMA endpoint by itself with or > >> without any extra namespaces. In fact, to conform to this reasoning, the > >> "right" thing to do would be to change the code already in upstream to get > >> rid of the listening RDMA endpoint in init_net! > > > > Actually I think they all already need user co-ordination? > > > > - NFS, user has to setup and load exports > > - Storage Targets, user has to setup the target > > - IPoIB, user has to set the link up > > > > etc. > > > > Each of those could provide the anchor to learn the namespace. > > My two cents, and worth every penny: > > I think the NFSD listener is net namespace-aware. I vaguely recall > that a user administrative program (maybe rpc.nfsd?) requests an > NFS service listener in a particular namespace. > > Should work the same for sockets and listener QPs. For RPC-over-RDMA, > a struct net argument is passed in from the generic code: > > 66 static struct svcxprt_rdma *svc_rdma_create_xprt(struct svc_serv *serv, > 67 struct net *net); > 68 static struct svc_xprt *svc_rdma_create(struct svc_serv *serv, > 69 struct net *net, > 70 struct sockaddr *sa, int salen, > 71 int flags); > > And that struct net is then passed on to rdma_create_id(). Yes It might help Ka-Cheong to explore how NFS should work Jason
