On Tue, 2006-08-15 at 09:58 -0700, Sean Hefty wrote: > >The qkeys used by the RDMA CM sound like they may be the problem. I'll > >verify > >this and see how to fix it if so. > > If I set the qkeys for the QPs and MCMemberRecord to 0, I can get this to work > now. The RDMA CM uses a qkey = port number for UD QPs, and a qkey = IPv4 > address for MCMemberRecords. > > A potential fix I see for this is to use the same qkey for all UD QPs and > multicast groups created by the RDMA CM. Otherwise we restrict UD QPs to > using > a single destination (remote UD QP or multicast group.) >
I was marching to the same tune! But I have a few points needing clarification. In my IP-centric mind, the sender specifies the ip mcast address and a remote port. All hosts with subscribers to the ip mcast address get the packet, and all sockets on those hosts who are bound to the dst_port receive a copy. Other sockets on those hosts that joined the ipmcast group but are bound to different ports will _not_ get a copy of the packet. In addition, the sender's local port number doesn't matter at all in the equation. Now how does that translate to qkeys, udqops, and ib mcast? It sounds to me like the remote_qkey is used to identify the mcast group when sending a mcast -and- to identify the set of qps on each host that should receive the incoming mcast packets. Is this true? _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general