[openib-general] multicast code/merge status

[Or Gerlitz]

On 1/17/07, Sean Hefty <mshefty at ichips.intel.com> wrote:
> > +1 used only for unicast
> > +2 used only for multicast
> > +3 used for both unicast and multicast

> If you view this as the use case for one side only, we also have option 3
> communicating with options 1 and 2.  I would list these as:

OK

> +4 unicast QP to unicast and multicast QP

i think you mean 3 <--> 1 that is unicast and multicast QP to unicast QP

> +5 multicast QP to unicast and multicast QP

i think you mean 3 <--> 2 that is unicast and multicast QP to multicast QP

> Today, all of these work.  What you're wanting to add is the ability to
> communicate with an ipoib multicast group.  I'd like to do this without breaking
> any of the existing communications, or treat ipoib separately for security reasons.

makes sense, so my suggestion is "leave this (using the ipoib qkey) to
the user"
if you prefer to have two group types: rdmacm and ipoib - that's fine.
we would use ipoib type groups and in the envs that seting the qkey to
be the ipoib would not break our communication (that is where we do
need to interop with IPoIB) - we would do it, else we would do
nothing.

> > To make things simple, the solution i suggest is that that the RDMA CM
> > would --not-- do this modify QP/QKEY (that is would set the 0x12345678
> > qkey on the modify qp to init) and rather leave it to the RDMA CM
> > consumer --if-- they wish to do so. However it will use the ipv4
> > broadcast group qkey for doing mcast joins and report this qkey to the
> > user in the ud param of the event.
>
> We need to be able to handle options 4 and 5 as well.

indeed, i have addressed that above.

> > this (what qkey is assigned to the ipv4 broadcast group by different
> > SAs) is orthogonal to the discussion we do here.

> This depends on whether verbs allows, or if it should allow, a user to specify a
> controlled qkey when configuring their QP.

I don't think there is any limitation today in the verbs layer,
actually for our testing so far we patches the rdmacm not set the sig
byte and use the ipoib (ie not override it in core/cma.c)  and we
manage to interop fine with ipoib.