BIRD Journey to Threads: Chapter zero of a blogpost series

[Maria Matejka]

Hello!

Well, there are several branches spread across the repository, keeping 
different stages of development, mostly buggy or badly designed in some 
way, with cherry-picks and rebases everywhere.

To see something that seems to be useful (and mostly final) even for 
now, look at the commit c78f88c91c7b75f530d70d503fa011c20f16f278 (yes, 
not even a branch, just a commit deep in a repository). The locking code 
in that branch may get simplified before release.

There is also a branch named 'guernsey' (for completely unrelated 
reasons; yes, it is chaotic) where you can see the (unfinished) next 
chapter of this series together with lots of other stuff related to 
route storage. This branch may be rebased or otherwise amended with no 
warning.

There is also some code not to be used, testing some design ideas, like 
parts of branches 'mq-async-export' and 'jersey'. We may cherry-pick 
some changes from there.

Parts of the code are also still not written (e.g. most of the changes 
in route export) and I'm going to code these after writing the 
documentation, instead of documenting what the code does.

You are also right that the last version is currently 2.0.7; the pace of 
ordinary releases has dropped down a bit as we spend quite a lot of time 
thinking about multithreading design.

Maria

On 3/16/21 12:36 PM, Douglas Fischer wrote:
> 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/ <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 <mailto: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