> IPoIB permanently caches PRs with no mechanism in place to keep them > in sync with the SA. The goal is to limit the PR lifetime to prevent > the use of stale paths. > > A side benefit of limiting the PR scope to a neighbour is that > different neighbours could use different paths, versus using a single > path per DGID.
OK, that makes sense. However, I don't think we want to do a path record lookup for every unicast ARP send, right? So I think we have to have some table of DGID -> AH mappings independent of the ipoib_neigh stuff. Adding a reference count to the path structure as you mentioned before makes sense to me. The only slightly ugly thing is handling dropping the reference when an ARP send completes, but I guess that should be possible to do somehow. Or were you suggesting using the existing AH reference counting and letting that handle things? That makes sense to me and actually seems pretty elegant. - 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
