> Whenever an illegal multicast address is passed to IPoIB for it to join it > stops all > subsequent requests from being joined. That happens because IPoIB joins to > multicast > addresses in the order they arrived and doesn't handle the next group's join > until the > current join finishes with success. This phenomena happens a lot when a > bonding interface > enslaves IPoIB devices. Before enslaving IPoIB interfaces the bonding device > acts like an > Ethernet device, including the way it translates muticast IP addresses to HW > addresses. When > it comes up without slaves it translates the group 224.0.0.1 (all hosts) as > if it were an > Ethernet device and when it enslaves IPoIB devices this is the address that > they get for > joining (which is a garbage for them)
Wouldn't it make more sense to fix the bonding device or core networking (wherever the problem is) so that it recomputes the multicast list when the bonding hardware type changes? After this patch, do we end up with an IPoIB interface that's not a member of the all hosts multicast group? (That seems like it would lead to confusing breakage later) - R. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
