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

Reply via email to