[openib-general] multicast code/merge status

[Sean Hefty]

> +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:

+4 unicast QP to unicast and multicast QP
+5 multicast QP to unicast and 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.

> 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.

> 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.

- Sean