On 01/06/16(Wed) 15:31, David Gwynne wrote: > currently it leaves early if it is the last entry being removed, > which is an optimisation. in the future it is possible for another > cpu to have a reference to the table while the last reference is > being dropped, so we need to scrub it in case it gets read.
Are you saying that the counter of routes inside a table will be incremented in other places? Currently the only place where I used it as a "reference" counter is in art_table_walk(). Note that this is a difference with the original design, so I'd appreciate a commenter explaining why we do not remove the table at this point. I tried to keep the code as close as the pseudo algorithm described in the paper as possible. I thought that this would help readers understanding it. Or should we use a different field? > ok? > > Index: art.c > =================================================================== > RCS file: /cvs/src/sys/net/art.c,v > retrieving revision 1.14 > diff -u -p -r1.14 art.c > --- art.c 13 Apr 2016 08:04:14 -0000 1.14 > +++ art.c 1 Jun 2016 05:26:51 -0000 > @@ -490,10 +490,6 @@ art_table_delete(struct art_root *ar, st > KASSERT(prev == node); > #endif > > - /* We are removing an entry from this table. */ > - if (art_table_free(ar, at)) > - return (node); > - > /* Get the next most specific route for the index `i'. */ > if ((i >> 1) > 1) > next = at->at_heap[i >> 1].node; > @@ -512,6 +508,9 @@ art_table_delete(struct art_root *ar, st > else > at->at_heap[i].node = next; > > + /* We have removed an entry from this table. */ > + art_table_free(ar, at); > + > return (node); > } >
