[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