On Mon, Feb 05, 2018 at 09:33:07AM -0600, Steve Wise wrote: > Hey Leon, > > > > > It is opposite, cm_id is a unique number, but other objects don't have > > such. What about PD and CQ? > > > > We can declare that access to QP .doit willbe based on QPN, PD .doit > > will be based on local_dma_lkey, but what will be CQ identifier? > > > > Now that I've thought about this more, I realize the core verbs data > structures don't have identifiers for most objects. I'm not sure why the > qp_num is exposed, but I guess it is because the qp num values must be > exchanged between both ends of an IB connection to setup the connection. > > The local_dma_lkey value will not be unique for each PD. For all iwarp > devices the local_dma_lkey is 0. (I think the same is true for IB devices). > So PD has the same issue as CQ. > > I suppose we can use rkey for MRs, but if the MR is not in the VALID state, > the rkey isn't necessarily accurate (the LSB of the rkey can be changed by > the application with each REG_MR operation). > > The cm_id doesn't have any unique identifier either, except maybe the > combination of src/dst addresses and port space. > > With iw_cxgb4, CQs, PDs, and MRs all have a unique identifier just like a QP > does. I expect all hw implementations of rdma have numeric identifiers for > CQs, PDs, QPs, etc. They aren't exposed to the core API though. > > Perhaps we add a device-unique (or globally unique) identifier as part of > the restrack struct and use that for GET/SET? +1, I like it, it is very clean. Thanks > > Steve. >
Attachment:
signature.asc
Description: PGP signature
