Jason Gunthorpe wrote:
Nir Muchtar wrote:
It is tied to the ucma_fops FD (ie /dev/rdma_cm, aka the event
channel), which when closed calls ucma_free_ctx which calls rdma_destroy_id.
Processes that can access that FD can control the RDMA CM IDs associated with
it.
The only case where this
On Tue, 2010-12-21 at 13:36 -0700, Jason Gunthorpe wrote:
The question is how do your correlate the kernel ID with the userspace
process(es) that have ownership of it. The only way to do that is to
associate the ID with the event channel FD with the process(es) that
have access to it.
On Mon, 2010-12-20 at 14:54 -0700, Jason Gunthorpe wrote:
On Sun, Dec 19, 2010 at 04:36:22PM +0200, Nir Muchtar wrote:
On Tue, 2010-12-14 at 11:34 -0700, Jason Gunthorpe wrote:
On Mon, Dec 13, 2010 at 06:22:49PM +0200, Nir Muchtar wrote:
Save owning PID to id-priv when creating
On Tue, Dec 21, 2010 at 05:05:50PM +0200, Nir Muchtar wrote:
But an RDMA CM ID is not a FD based resource. An event channel is, but I
want to export ID stats and not event channel stats.
Are you saying that there's a scenario in which an RDMA CM ID is shared
between multiple processes?
It
Jason Gunthorpe wrote:
But an RDMA CM ID is not a FD based resource. An event channel is, but I
want to export ID stats and not event channel stats.
Are you saying that there's a scenario in which an RDMA CM ID is shared
between multiple processes?
It *is* a FD based resource. Nearly
These are some of the differences
from the socket interface, which immediately creates a kernel resource
for each FD that is opened.
Not immediately of course, but you understand my point hopefully...
Nir
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a
On Tue, Dec 21, 2010 at 09:43:01PM +0200, Nir Muchtar wrote:
Jason Gunthorpe wrote:
But an RDMA CM ID is not a FD based resource. An event channel is, but I
want to export ID stats and not event channel stats.
Are you saying that there's a scenario in which an RDMA CM ID is shared
On Sun, Dec 19, 2010 at 04:36:22PM +0200, Nir Muchtar wrote:
On Tue, 2010-12-14 at 11:34 -0700, Jason Gunthorpe wrote:
On Mon, Dec 13, 2010 at 06:22:49PM +0200, Nir Muchtar wrote:
Save owning PID to id-priv when creating id's/accepting connections.
This should be called creator_pid, not
On Tue, 2010-12-14 at 11:34 -0700, Jason Gunthorpe wrote:
On Mon, Dec 13, 2010 at 06:22:49PM +0200, Nir Muchtar wrote:
Save owning PID to id-priv when creating id's/accepting connections.
This should be called creator_pid, not owner - to avoid confusion.
But it's meant to be the owner and
On Mon, Dec 13, 2010 at 06:22:49PM +0200, Nir Muchtar wrote:
Save owning PID to id-priv when creating id's/accepting connections.
This should be called creator_pid, not owner - to avoid confusion.
It may be better to not include it at all. See next letter
Jason
--
To unsubscribe from this
Save owning PID to id-priv when creating id's/accepting connections.
Signed-off-by: Nir Muchtar n...@voltaire.com
---
drivers/infiniband/core/cma.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index
11 matches
Mail list logo
