RFC: Upgrade filter integer size to 64-bit
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
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :) -Toke
I need to agree with Toke! "having Bird behave differently on different archs is bound to be incredibly confusing..." And, on the other hand, what would be the downside of having everything in 64? Using a little more memory than might be the minimum usable? This kind of care I see being taken for applications that run platforms with serious memory limitations. I don't see that this is BIRD's niche. In a real scenario of high demand using BIRD, how much memory would be "wasted"? In these real high demand scenarios, who uses 32bit these days? I would worry more about CPU cycles. Em sáb., 26 de mar. de 2022 às 19:19, Toke Høiland-Jørgensen <toke@toke.dk> escreveu:
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :)
-Toke
-- Douglas Fernando Fischer Engº de Controle e Automação
Is there even any userbase running bird on embedded hardware (that might be adversely affected)? Dn42 comes to mind. Perhaps? But realistically we aren't talking about much of an increase surely? Other than that I like 64bit only. On Mon, 28 Mar 2022, 10:20 pm Douglas Fischer, <fischerdouglas@gmail.com> wrote:
I need to agree with Toke! "having Bird behave differently on different archs is bound to be incredibly confusing..."
And, on the other hand, what would be the downside of having everything in 64? Using a little more memory than might be the minimum usable?
This kind of care I see being taken for applications that run platforms with serious memory limitations. I don't see that this is BIRD's niche.
In a real scenario of high demand using BIRD, how much memory would be "wasted"? In these real high demand scenarios, who uses 32bit these days?
I would worry more about CPU cycles.
Em sáb., 26 de mar. de 2022 às 19:19, Toke Høiland-Jørgensen <toke@toke.dk> escreveu:
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :)
-Toke
-- Douglas Fernando Fischer Engº de Controle e Automação
We do have use cases where we run BIRD in low memory environments with a lot of routes in the kernel, so moving everything to 64-bits could potentially hurt these scenarios. Option #3 would be very confusing, so we'd have to vote for keeping things as is. Thanks, Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly> On Mon, Mar 28, 2022 at 5:04 AM Mathew Heard <me@mheard.com> wrote:
Is there even any userbase running bird on embedded hardware (that might be adversely affected)?
Dn42 comes to mind. Perhaps? But realistically we aren't talking about much of an increase surely?
Other than that I like 64bit only.
On Mon, 28 Mar 2022, 10:20 pm Douglas Fischer, <fischerdouglas@gmail.com> wrote:
I need to agree with Toke! "having Bird behave differently on different archs is bound to be incredibly confusing..."
And, on the other hand, what would be the downside of having everything in 64? Using a little more memory than might be the minimum usable?
This kind of care I see being taken for applications that run platforms with serious memory limitations. I don't see that this is BIRD's niche.
In a real scenario of high demand using BIRD, how much memory would be "wasted"? In these real high demand scenarios, who uses 32bit these days?
I would worry more about CPU cycles.
Em sáb., 26 de mar. de 2022 às 19:19, Toke Høiland-Jørgensen < toke@toke.dk> escreveu:
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :)
-Toke
-- Douglas Fernando Fischer Engº de Controle e Automação
Option 2 please On Mon, 28 Mar 2022 at 09:55, Trisha Biswas <tbiswas@fastly.com> wrote:
We do have use cases where we run BIRD in low memory environments with a lot of routes in the kernel, so moving everything to 64-bits could potentially hurt these scenarios. Option #3 would be very confusing, so we'd have to vote for keeping things as is.
Thanks, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Mon, Mar 28, 2022 at 5:04 AM Mathew Heard <me@mheard.com> wrote:
Is there even any userbase running bird on embedded hardware (that might be adversely affected)?
Dn42 comes to mind. Perhaps? But realistically we aren't talking about much of an increase surely?
Other than that I like 64bit only.
On Mon, 28 Mar 2022, 10:20 pm Douglas Fischer, <fischerdouglas@gmail.com> wrote:
I need to agree with Toke! "having Bird behave differently on different archs is bound to be incredibly confusing..."
And, on the other hand, what would be the downside of having everything in 64? Using a little more memory than might be the minimum usable?
This kind of care I see being taken for applications that run platforms with serious memory limitations. I don't see that this is BIRD's niche.
In a real scenario of high demand using BIRD, how much memory would be "wasted"? In these real high demand scenarios, who uses 32bit these days?
I would worry more about CPU cycles.
Em sáb., 26 de mar. de 2022 às 19:19, Toke Høiland-Jørgensen < toke@toke.dk> escreveu:
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :)
-Toke
-- Douglas Fernando Fischer Engº de Controle e Automação
Hello Trisha! This scenario you mentioned made me curious! Can you comment a little (as far as possible respecting contracts) how is this scenario with little memory and many Kernel routes? What kind of hardware? Where would this be applied? Em seg., 28 de mar. de 2022 às 13:55, Trisha Biswas <tbiswas@fastly.com> escreveu:
We do have use cases where we run BIRD in low memory environments with a lot of routes in the kernel, so moving everything to 64-bits could potentially hurt these scenarios. Option #3 would be very confusing, so we'd have to vote for keeping things as is.
Thanks, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Mon, Mar 28, 2022 at 5:04 AM Mathew Heard <me@mheard.com> wrote:
Is there even any userbase running bird on embedded hardware (that might be adversely affected)?
Dn42 comes to mind. Perhaps? But realistically we aren't talking about much of an increase surely?
Other than that I like 64bit only.
On Mon, 28 Mar 2022, 10:20 pm Douglas Fischer, <fischerdouglas@gmail.com> wrote:
I need to agree with Toke! "having Bird behave differently on different archs is bound to be incredibly confusing..."
And, on the other hand, what would be the downside of having everything in 64? Using a little more memory than might be the minimum usable?
This kind of care I see being taken for applications that run platforms with serious memory limitations. I don't see that this is BIRD's niche.
In a real scenario of high demand using BIRD, how much memory would be "wasted"? In these real high demand scenarios, who uses 32bit these days?
I would worry more about CPU cycles.
Em sáb., 26 de mar. de 2022 às 19:19, Toke Høiland-Jørgensen < toke@toke.dk> escreveu:
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :)
-Toke
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Douglas Fernando Fischer Engº de Controle e Automação
Hello! I'm curious as well and I'd like to ask you also, if you could, to send me (privately) a binary and a corefile of such a case you are writing about. I'll inspect the memory and tell exactly how much you'd be affected by the u32->u64 change. Thanks a lot! Maria On March 28, 2022 8:18:09 PM UTC, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Hello Trisha!
This scenario you mentioned made me curious!
Can you comment a little (as far as possible respecting contracts) how is this scenario with little memory and many Kernel routes?
What kind of hardware? Where would this be applied?
Em seg., 28 de mar. de 2022 às 13:55, Trisha Biswas <tbiswas@fastly.com> escreveu:
We do have use cases where we run BIRD in low memory environments with a lot of routes in the kernel, so moving everything to 64-bits could potentially hurt these scenarios. Option #3 would be very confusing, so we'd have to vote for keeping things as is.
Thanks, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Mon, Mar 28, 2022 at 5:04 AM Mathew Heard <me@mheard.com> wrote:
Is there even any userbase running bird on embedded hardware (that might be adversely affected)?
Dn42 comes to mind. Perhaps? But realistically we aren't talking about much of an increase surely?
Other than that I like 64bit only.
On Mon, 28 Mar 2022, 10:20 pm Douglas Fischer, <fischerdouglas@gmail.com> wrote:
I need to agree with Toke! "having Bird behave differently on different archs is bound to be incredibly confusing..."
And, on the other hand, what would be the downside of having everything in 64? Using a little more memory than might be the minimum usable?
This kind of care I see being taken for applications that run platforms with serious memory limitations. I don't see that this is BIRD's niche.
In a real scenario of high demand using BIRD, how much memory would be "wasted"? In these real high demand scenarios, who uses 32bit these days?
I would worry more about CPU cycles.
Em sáb., 26 de mar. de 2022 às 19:19, Toke Høiland-Jørgensen < toke@toke.dk> escreveu:
Maria Matejka <maria.matejka@nic.cz> writes:
Is there anybody who would try to convince me that I shouldn't make filter integers and route attribute integers both 64 bits wide?
I think switching everything to 64-bits sounds quite sensible. Whatever you do, please don't go with option 3, though, having Bird behave differently on different archs is bound to be incredibly confusing... :)
-Toke
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Douglas Fernando Fischer Engº de Controle e Automação
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
participants (7)
-
Darren O'Connor -
Douglas Fischer -
Maria Matejka -
Maria Matějka
-
Mathew Heard -
Toke Høiland-Jørgensen -
Trisha Biswas