[openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
Hal Rosenstock
halr at voltaire.com
Wed Feb 21 14:53:22 PST 2007
On Wed, 2007-02-21 at 17:36, Sean Hefty wrote:
> > 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?
Nope.
> I can't think of any reason to do such a thing,
Me neither. It would be a configuration error of sorts.
> 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.
I'm not sure it's this patch in particular but it appears that there may
be some non compliant behavior being exercised IMO.
-- Hal
> - Sean
More information about the general
mailing list