BIRD Journey to Threads: Chapter zero of a blogpost series

[Douglas Fischer]

I'm trying to understand a bit deeper the new concepts of multithreading of
Bird.

You mentioned:
"and a programmer's documentation composed mostly of comments spread across
the source code"

So I decided to dig a bit on the code available at
https://gitlab.nic.cz/labs/bird/ to look at the comments, try to understand
the concepts...
But I could not find any tags earlier than 1 year. No releases bigger than
2.0.7. No Milestones.

Is reasonable to consider that this innovative part of the code is still no
publicly available?

How someone that "want to know how BIRD works internally and how it is
going to change" could look a bit more directly to that part of the code
changes?

Em seg., 15 de mar. de 2021 às 15:02, Maria Matejka <maria.matejka at nic.cz>
escreveu:

> Hello!
>
> On 3/15/21 6:07 PM, Douglas Fischer wrote:
> > That part about "Filter Rework" made me a bit anxious!
> > I don't know exactly means the part:
> >   "we decided to preprocess the filter internal structure to another
> > structure which is much easier to execute"...
> > But, to me, it sounds like fragmenting, even more, the "test, mark, and
> > actuate" on the filters... Right?
>
> This is a work that has been already included in v2.0.x for x ≥ 4 as far
> as I can remember. The filter is simply converted (in config time) from
> an infix structure with lots of pointers to a stack-oriented postfix
> bytecode.
>
> That bytecode is somehow similar to Lua. We also thought about using Lua
> itself as a filtering language, anyway we had problems with Lua stack
> initialization. A simple run of an empty filter took at least 2 us on
> our testing machine, compared to 35 ns of our empty filter.
>
> > Talking about BGP, I love Bird because only with it I know how to do
> > what I call "2 cycles filtering"...
> >
> > - I create several Small Tests, where each route is tested and marked
> > somehow...
> > - On each Peer-Type, import or export(but mostly on import), and I
> > define which tests will be called to be executed on that route, and live
> > their mark on each route.
> >    - I here I test, Mask-lenght, AS-Set, AS-Origin, AS-Path,
> > foreigner-communities, internal-communities, a lot of Regex, and all
> > those multiple complex things...
> > - And at the end of the filter-police I do an "IF" that tests on a
> > combined And+Or the marks lived by the previous tests, and based on that
> > do the accept, reject, add-communities, adjust MED/Local-Pref/Etc...
>
> This stays the same, the filter language didn't change, we just reworked
> the interpreter. To add to this, there are also custom route attributes.
> It is quite common to do the small test on import, store the results to
> BGP communities, decide on export based on them and then filter them
> out. For this use, you can define your own route attributes and you
> don't mess with the communities at all. (And these are also faster than
> community list manipulation.)
>
> We are thinking about more filtering features like iterating over the
> community lists or multipath nexthops. Don't worry, the filters are
> going to stay the same or better.
>
> Thank you for your input!
>
> Maria
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210316/31ac2f61/attachment.htm>