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 *is* a FD based resource. Nearly everything in Linux is. 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 is not true is in the kernel, and in that instance the PID is meaningless - you'd be much better off exporting the name of the module that allocated the RDMA CM ID. > Even if there is such a scenario, I think that by taking the PID of the > one that calls rdma_accept, the idea of an owner stays consistent. > I don't mind the name btw, just tying it to something else, which isn't > necessarily related. The proper thing for userspace is to tie it back to the FD that owns the resource - which is the FD that destroys the resource when it is closed. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
