[openib-general] multicast code/merge status

Or Gerlitz ogerlitz at voltaire.com
Tue Jan 9 05:20:44 PST 2007


Michael S. Tsirkin wrote:
>>> I currently have these in separate branches.  I know that Woody has them
>>> combined in his tree, but I can create an 'ofed' branch with these together.
>> I published a 'multicast-sa_cache' branch (which was a little clearer than
>> 'ofed').  I can change the name if more patches need to be pulled in.
> 
> Cool, thanks, I'll try to put these in ofed next week.

Hi Sean,

My thought re this was that since the rest of the original patch 
sequence specifically the rdma_cm UDP and ucma code are merged in 
2.6.20-rcX which is the code OFED 1.2 is based on, the easy path for you 
would be to stage the multicast code for upstream push to 2.6.21 and 
then push the code as to OFED 1.2, what do you think?

Other then that, as we discussed in SC06 there are some changes that 
need to be integrated in the code to allow for interoperability between 
a multicast rdma cm based app to IPoIB, specifically removing the RDMA 
CM signature from the mgid which generated from the ip addr and pkey, 
but not only.

The second change is related to the qkey, looking in the current code
of cma_join_ib_multicast() (at the multicast-sa_cache branch of the 
rdma-dev git) i see that the qkey is the mc ip address, which is not 
consistent with what librdmacm is assuming (0x1234567 etc).

Anyway, what we need here is to plug into the scheme of ipoib which uses 
  the qkey associated with the ipv4 broadcast multicast group. It turns 
out that there is some twilight zone here which i am working to 
understand better. You can see that for the ipv4 brd group ipoib lets 
the SM to allocate the group and qkey (ie the create param of 
ipoib_mcast_join is zero), i will give it some thought and let you know 
how i think the rdma cm can plug into this scheme, will be happy to get 
  other ideas as well.

Or.







More information about the general mailing list