> > + memset(rec, 0, sizeof *rec); > > + ib_get_cached_gid(device, port_num, 0, &rec->port_gid); > > + rec->pkey = 0xFFFF; > > + get_random_bytes(&rec->qkey, sizeof rec->qkey); > > + rec->join_state = 1; > > + } > > Where is this particular hard-coded P_Key value coming from? And how > about the Q_Key -- why is a random one being chosen? Does it matter > that this is setting the privileged bit of the Q_Key at random?
The idea behind this part of the call was to return the user an MCMemberRecord that they can use to create a new multicast group. Maybe it would be better to just drop this functionality and fail any lookups for mgid 0, but to answer your questions: The pkey is the default partition, full membership pkey. I believe all nodes will have either 0xffff or 0x7fff as their pkey. We could probably call ib_get_cached_pkey() instead and just use the first entry in the table. We don't want to to set the privileged bit of the q_key, so that's wrong. Good catch. > The only place this code seems to be used is in > cma_join_ib_multicast(), which overwrites all the values that get set > here anyway. (Except it leaves the Q_Key if the portspace is not UDP??) > Would it be more sensible to leave the P_Key and Q_Key initialized to > 0 here, and let the caller handle it? I don't see how the multicast > tracking module can pick a sensible default here. The user can overwrite any of the values that they don't like as defaults before sending the actual join. > Also, should we check the return value of ib_get_cached_gid()? That is probably best. There's shouldn't be much harm if the call fails; the MCMemberRecord will be invalid, and the future join request will fail. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
