On Tue, Feb 06, 2018 at 10:40:19AM +0200, Leon Romanovsky wrote:
> On Mon, Feb 05, 2018 at 03:20:25PM -0700, Jason Gunthorpe wrote:
> > On Mon, Feb 05, 2018 at 04:16:37PM -0600, Steve Wise wrote:
> > > >
> > > > On Mon, Feb 05, 2018 at 02:53:23PM -0600, Steve Wise wrote:
> > > >
> > > > > Even if we create a device-unique ID for each restrack object, to make
> > > it
> > > > > useful to for userspace analysis would require exposing that ID in the
> > > > > various user object structures (or via query methods). EG having
> > > > > pd->res_id, cq->res_id, etc...
> > > >
> > > > As I said, we have that, it is the fd, handle # tuple and most verbs
> > > > objects expose the handle # in the user visible part of the object
> > > > struct..
> > >
> > > Can you please show me an example of the handle # for some object like PD or
> > > CQ?
> >
> > From rdma-core verbs.h:
> >
> > struct ibv_pd {
> > struct ibv_context *context;
> > uint32_t handle;
> > };
> >
> > > This doesn't address kernel users' object, though, correct?
> >
> > Right.
> >
> > And id'ing a file descriptor gets kinda hard too..
>
> And how should we handle kernel objects?
hash'd pointer to internal struct?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
