> It does this since its makes life simple and robust. Is an SM prevented from loading two PKeys into an HCA's PKey table that differ by only the membership bit?
I can't think of any reason to do such a thing, but depending on which index was selected could limit which nodes you could communicate with. > Note that since the HCA validates the pkey in the in coming packet, no > matter what the IB SW would do, partial members of a partition can't > talk to each other. So the approach taken by the core/ipoib code was > to just ignore the MSb in places where the code looks for the pkey > --index-- and use the full member pkey when forming MGIDs. This seems > fine to me. My concern is that ib_find_cached_pkey() returns an index to a pkey that wasn't the one in the search. Can this lead to a QP being configured in such a way that communication with a remote QP would silently fail? I realize that a user could call ib_get_cached_pkey and see if the returned value matches the one in the original search, but this is a non-obvious way to check for a mismatch. I'm not against this patch, but I want to make sure that I understand the issues, so we're not creating a work-around solution. The patch is against the librdmacm, yet there's nothing that I see in the librdmacm that makes me think it's behaving incorrectly. - Sean _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general