[adding back to list] On Tue, 2006-08-15 at 11:59 -0700, Sean Hefty wrote:
> > >For type SOCK_DGRAM (UDP), the socket will receive packets from multiple > >subscribed ip mcast groups iff the dst_port of the incoming packet > >matches the port to which the socket is bound... > > This is what I was referring to. I'm really not familiar with IP multicast > beyond what I read in a book while coding the RDMA CM. It sounds like we > might > be able to use the QKey as the port number for the QP to mimic the behavior. > > The RDMA CM sets the QKey for UD QPs to the port number, but sets the QKey of > a > multicast group to the IPv4 address. > > >NOTE: I'm just trying to understand how this works in IB. I'm not > >necessarily advocating it should behave exactly like ip mcast/udp. > > Clients need to create an UD QP. When they join a multicast group, they get > an > MGID, MLID, and QKey. The UD QP needs to attach to the MGID / MLID, and have > a > matching QKey. Today, the RDMA CM assigns a QKey to a UD QP when it's > created; > it doesn't know if it will join a multicast group or not. > Looking at the mckey code, I see that the code calls rdma_get_dst_attr() to get the remote qpn/qkey + the ah_attrs for the mcast group (which is the dst addr in this case). Then it creates an ibv_ah. Later when sending, the SEND WR contains both the ah and the remote qpn/qkey. Why are these separated? Isn't an address handle needed for each destination QP? If so, then why is the remote qpn/qkey also needed to transmit a datagram? Trying to understand how ah's relate to qpn/qkeys... _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
