Download raw body.
use the SMR api instead of SRPs in art/rtable code
On 26/06/2025 05:46, Hrvoje Popovski wrote: > 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 ... thanks hrvoje. i think i'll commit it soon.
use the SMR api instead of SRPs in art/rtable code