> > > > > > 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 This should be done to a subsequent series. Perhaps when GET/SET are actually implemented... Steve. -- 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
