Jonathan Matthew([email protected]) on 2016.06.06 17:14:53 +1000: > We've finally got srp and art to the point where we can use srp to manage the > internal links in the art data structures. This allows us to do route lookups > without holding any locks, which is kind of nice. > > As we're not doing unlocked insert, delete or walk (yet), those art functions > use the locked variants of the srp functions. Currently the lock that > protects those operations is the kernel lock. > > Callers to art_lookup and art_match now pass in a pointer to an srp_ref, which > is always active on return, even if no route is found. In some situations we > use these functions while modifying the routing table, in which case the > kernel lock already protects against concurrent modifications so the srp_ref > is unnecessary, so we srp_leave it immediately. > > I'd also like to draw attention to the comment in rtable_match. Is it OK that > we might choose a multipath route at random if the set of available routes > changes while we're choosing?
i dont see why this would be a problem however: + ... if we were going to use + * the last available route, but it got removed, we'll hit + * the end of the list and then pick the first route. would this make the first route get more traffic than the others, statistically?
