All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: RDMA subsystem namespace related questions (was Re: Finding the namespace of a struct ib_device)
Date: Mon, 5 Oct 2020 10:16:11 -0300	[thread overview]
Message-ID: <20201005131611.GR9916@ziepe.ca> (raw)
In-Reply-To: <5ab6e8df-851a-32f2-d64a-96e8d6cf0bc7@oracle.com>

On Mon, Oct 05, 2020 at 06:27:39PM +0800, Ka-Cheong Poon wrote:
> On 10/2/20 10:04 PM, Jason Gunthorpe wrote:
> > > that namespace to use it.  If there are a large number of namespaces,
> > > there won't be enough devices to assign to all of them (e.g. the
> > > hardware I have access to only supports up to 24 VFs).  The shared
> > > mode can be used in this case.  Could you please explain what needs
> > > to be done to support a large number of namespaces in exclusive
> > > mode?
> > 
> > Modern HW supports many more than 24 VFs, this is the expected
> > interface
> 
> Do you have a ballpark on how many VFs are supported?  Is it in
> the range of many thousands?

Yes

> BTW, while the shared mode is still here, can there be a simple
> way for a client to find out which mode the RDMA subsystem is using?

Return NULL for the namespace

> > The new cm_id starts with the same ->context as the listener, the ULP should
> > use this to pass any data, such as the namespace.
> 
> This is what I suspected as mentioned in the previous email.  But
> this makes it inconvenient if the context is already used for
> something else.

Don't see why. the context should be allocated memory, so the ULP can
put several things lin there.

> > I'm skeptical ULPs should be doing per-ns stuff like that. A ns aware
> > ULP should fundamentally be linked to some FD and the ns to use should
> > derived from the process that FD is linked to. Keeping per-ns stuff
> > seems wrong.
> 
> 
> It is a kernel module.  Which FD are you referring to?  It is
> unclear why a kernel module must associate itself with a user
> space FD.  Is there a particular reason that rdma_create_id()
> needs to behave differently than sock_create_kern() in this
> regard?

Somehow the kernel module has to be commanded to use this namespace,
and generally I expect that command to be connected to FD.

We don't have many use cases where the kernel operates namespaces
independently..

> While discussing about per namespace stuff, what is the reason
> that the cma_wq is a global shared by all namespaces instead of
> per namespace?  Is there a problem to have a per namespace cma_wq?

Why would we want to do that?

Jason

  reply	other threads:[~2020-10-05 13:16 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03 14:02 Finding the namespace of a struct ib_device Ka-Cheong Poon
2020-09-03 17:39 ` Jason Gunthorpe
2020-09-04  4:01   ` Ka-Cheong Poon
2020-09-04 11:32     ` Jason Gunthorpe
2020-09-04 14:02       ` Ka-Cheong Poon
2020-09-06  7:44         ` Leon Romanovsky
2020-09-07  3:33           ` Ka-Cheong Poon
2020-09-07  7:18             ` Leon Romanovsky
2020-09-07  8:24               ` Ka-Cheong Poon
2020-09-07  9:04                 ` Leon Romanovsky
2020-09-07  9:28                   ` Ka-Cheong Poon
2020-09-07 10:22                     ` Leon Romanovsky
2020-09-07 13:48                       ` Ka-Cheong Poon
2020-09-29 16:57                         ` RDMA subsystem namespace related questions (was Re: Finding the namespace of a struct ib_device) Ka-Cheong Poon
2020-09-29 17:40                           ` Jason Gunthorpe
2020-09-30 10:32                             ` Ka-Cheong Poon
2020-10-02 14:04                               ` Jason Gunthorpe
2020-10-05 10:27                                 ` Ka-Cheong Poon
2020-10-05 13:16                                   ` Jason Gunthorpe [this message]
2020-10-05 13:57                                     ` Ka-Cheong Poon
2020-10-05 14:25                                       ` Jason Gunthorpe
2020-10-05 15:02                                         ` Ka-Cheong Poon
2020-10-05 15:45                                           ` Jason Gunthorpe
2020-10-06  9:36                                             ` Ka-Cheong Poon
2020-10-06 12:46                                               ` Jason Gunthorpe
2020-10-07  8:38                                                 ` Ka-Cheong Poon
2020-10-07 11:16                                                   ` Leon Romanovsky
2020-10-08 10:22                                                     ` Ka-Cheong Poon
2020-10-08 10:36                                                       ` Leon Romanovsky
2020-10-08 11:08                                                         ` Ka-Cheong Poon
2020-10-08 16:08                                                           ` Jason Gunthorpe
2020-10-08 16:21                                                             ` Chuck Lever
2020-10-08 16:46                                                               ` Jason Gunthorpe
2020-10-09  4:49                                                             ` Ka-Cheong Poon
2020-10-09 14:39                                                               ` Jason Gunthorpe
2020-10-09 14:48                                                                 ` Chuck Lever
2020-10-09 14:57                                                                   ` Jason Gunthorpe
2020-10-09 15:00                                                                     ` Chuck Lever
2020-10-09 15:07                                                                       ` Jason Gunthorpe
2020-10-09 15:27                                                                         ` Chuck Lever
2020-10-09 15:34                                                                           ` Jason Gunthorpe
2020-10-09 15:52                                                                             ` Chuck Lever
2020-10-12  8:20                                                                             ` Ka-Cheong Poon
2020-10-16 18:54                                                                               ` Jason Gunthorpe
2020-10-16 20:49                                                                                 ` Chuck Lever
2020-10-19 18:31                                                                                   ` Jason Gunthorpe
2020-10-07 12:28                                                   ` Jason Gunthorpe
2020-10-08 10:49                                                     ` Ka-Cheong Poon

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=20201005131611.GR9916@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=ka-cheong.poon@oracle.com \
    --cc=linux-rdma@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.