[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