Roland Dreier wrote:
the only assumption is a unique lkey across the device. In my case, I am seeing a lkey of 0 returned for every memory region created on this device, however the rkey is changing.ardavis> I noticed ibv_reg_mr always returns the same lkey of 0 ardavis> (per device) which presents a problem with udapl since ardavis> the lkey is used as the context in the lmr hash table to ardavis> avoid re-use. Is there a reason that you choose not to ardavis> make this unique?
I'm not sure I follow the question. On my system ibv_reg_mr() returns a different, non-zero L_Key for each region that is registered. The L_Key is guaranteed to be unique among all the memory regions currently registered with a given device. I don't see how it's possible to get L_Key 0 for any memory region (since that L_Key is reserved by Mellanox HCA firmware), and I'm actually not sure what you mean by "0 (per device)."
If you are seeing mr->lkey == 0 after a call to ibv_reg_mr(), then something is going wrong either in your code or in libibverbs or libmthca. Can you post your code where you see that happen?
If uDAPL is assuming that L_Keys are globally unique even with multiple HCAs, then uDAPL needs to be fixed, since a completely compliant verbs implementation may not satisfy that condition.
- R.
mr_register: lkey=0x0, rkey=0x5 ln=72 priv=1
pingpong looks ok...
"ibv_reg_mr: mr 0x506ea0 mr->lkey a002c mr->rkey a002c" local address: LID 0x0012, QPN 0x010406, PSN 0xdd3db0
so nevermind...my bad! .I will dig a little deeper.
-arlin
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
