[openib-general] SA multicast patches
Sean Hefty
mshefty at ichips.intel.com
Thu Feb 15 14:39:47 PST 2007
> > + 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
More information about the general
mailing list