Dear fellow users of BIRD,
I'd like to do a quick survey. BIRD now uses a 32-bit unsigned integer
inside filters. OTOH, most of the integer route attributes are stored as
uintptr_t, which is 32-bit or 64-bit depending on architecture.
There are three basic options for further development:
1. Keep it as it is (32-bit filter integer, arch-dependent attribute
integer).
Pros:
* Lesser memory footprint of route attributes on 32-bit archs
Cons:
* 8-byte attributes (currently only Babel RouterID) stored indirectly
at least on 32-bit archs
* Explicit checks and transformations between filters and attributes
2. Update both to 64 bits.
Pros:
* Much more convenient development
Cons:
* More memory eaten on 32-bit archs (actual ratio depends on how many
route attributes you need to store)
* Slower computation of arithmetics in filters on 32-bit archs
3. Make it completely arch-dependent, either both 64-bit or both 32-bit.
Pros:
* Uses both 32-bit and 64-bit archs in their intended way
Cons:
* Different behavior of filters on different archs
* Possibly hard-to-discover architecture-dependent bugs
If it was on me, I'd choose to update everything to 64 bits and just
hope that the 32-bit use cases aren't affected too much. I suppose that
nobody is running BIRD at a low memory 32-bit box having lots of routes
in kernel with Linux kernel route metrics set, which is the worst case
scenario I can think about.
Is there anybody who would try to convince me that I shouldn't make
filter integers and route attribute integers both 64 bits wide?
Thank you all for your answers.
Maria
