>A straight-forward approach would be to listen for port up/down events >rather than or in addition to GID in/out, and do network discovery by DR SMPs.
I'm not entirely following you. How would you listen for port up/down events? And are you suggesting that all nodes do network discovery using DR SMPs? > Hmm. IPoIB by design does not handle heterogenious > networks too well (consider problems we have selecting bcast group rate). > MTU is also basically forced to 2K. > So this might not have been such a great example :) I agree; I just didn't want to create something that was worse than what we have now. >That's not entirely correct. For example, arp cache might get cleaned >by a timer, or by direct user request, or by other means. >When this happens, address handles and path records get freed. >Various IB events also trigger cache flush, such as the reregister event. I'm not overly familiar with the code. Is that what ipoib_neigh_destructor ends up doing? (I need to walk through this to see where the path is freed.) - Sean _______________________________________________ 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
