On Thu, 23 Sep 2010, Jason Gunthorpe wrote: > > IPoIB creates a infiniband multicast group via the IB calls for a IP > > multicast group. Then IGMP comes into play and the kernel sends the IP > > based igmp report. This igmp report must be received by an outside router > > (on an IP network) in order to for traffic to get forwarded into the IB > > fabric. You can end up with a IB multicast configuration that is all fine > > but with loss of the unsolicited packets due to fabric reconfiguration not > > being complete yet. The larger the fabric the worse the situation. > > But my point is that IB has very limited multicast, if I create a IB > group and then send IGMP into that group *it will not reach a router*.
The IPoIB routers automatically join all IP MC groups created. > The only way this kind of scheme could work is if an IGMPv2 IPoIB > router listens for IB MGID Create notices from the SA and > automatically joins all groups that are created, so it can get IGMPv2 > membership reports. Which obviously adds more delay, lag, and risk. Right that is how it works now. > I'm *guessing* that the change in IGMPv3 to send reports to 224.0.0.22 > (all IGMPv3 multicast address) is related to this sort of problem, and > it seems like on IB IGMPv2 is not a good fit and should not be used if > v3 is available.. Existing routers do no support IGMPv3. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
