On Wed, 2007-02-21 at 17:53, Hal Rosenstock wrote: > 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.
It is vendor dependent whether the SM would allow this. As Sasha points out, this cannot be done with OpenSM (at least currently). -- Hal > > 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 > > > _______________________________________________ > 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 > _______________________________________________ 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