Download raw body.
use the SMR api instead of SRPs in art/rtable code
On 13.6.2025. 8:44, David Gwynne wrote: > On Fri, Jun 13, 2025 at 12:03:37PM +1000, David Gwynne wrote: >> there's other changes too, but moving to SMR is the important one. >> >> SRPs complicated this code massively, so moving it to SMR is almost like >> backing the SRP changes out. it becomes a lot more readable and similar >> to other ART implementations, which can't hurt. >> >> another change is strip non-ART code out of art.c, specifically the >> rwlock and route sourceaddr info. these features have been moved >> up a layer into rtable.c and are now stored as part of a new struct >> rtable. again, this makes the art code easier to read and compare. >> >> the other big change is to walking over an ART. there's now a >> reentract and non-recursive iterator api which art_walk and rtable_walk >> are now built on top of. rtable_walk can basically do a foreach >> over the ART directly rather than having to pass a bunch of state >> into callbacks to apply with art_walk. we can still do that if we >> want, i just find this easier to deal with in rtable_walk directly. >> >> i modified how the heaps are traversed inside ART as well to try and >> minimise the pointer accesses as much as possible. >> >> i'm sorry the diff is so big. i don't expect code reviews. it took >> me 4 years and at least 3 attempts to do this diff. however, tests >> would be much appreciated. >> >> it looks like the generated code is smaller too. > apologies, i sent a slightly old version that missed some fixes around > reprio and mpath insertion. i didn't use scp enough before sending it > out. Hi, I'm running this diff on aggr, vlan, carp, pf, pfsync firewall and on same setup but with wireguard from the day you send this diff and everything seems to work just fine ...
use the SMR api instead of SRPs in art/rtable code