[openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey

[Sean Hefty]

> 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