Index | Thread | Search

From:
David Gwynne <david@gwynne.id.au>
Subject:
Re: use the SMR api instead of SRPs in art/rtable code
To:
Hrvoje Popovski <hrvoje@srce.hr>, tech@openbsd.org
Date:
Thu, 26 Jun 2025 10:11:13 +1000

Download raw body.

Thread

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.