Hello, before I begin... im just a sysadmin not a programmer I appreciate the work you are doing on OpenBGPd :) and I use it and im very happy
I saw Claudes presentation on openBGPd recently and how there was some work on MP for BGPd.. and I was wondering about an idea (I thought it was a simple thing which may be too simple ... please bear in mind Im not a professional programmer, basically I was wondering could there be a simple way of removing risk of having an MP RDE, from my understanding, one of the concerns about RDE being MP is a withdraw being received on process running on a busy processor , and a subsequent announce being received by a process running on a lighty loaded processor .. the announce being processed first and then the withdraw being processed afterwards... (there by withdrawing the route even though the announce was received after the withdraw) there are probably others... To get around the concern above.. could the Ip space be carved up between different processes so it is always the same process dealing with all messages to do with an address space) lets say with 2 core and 4 core Box for example Could you split the RDE into 2 RDE processes which would only process half of the IP space ? so for ip v4 0.0.0.0/0 (route decision engine on a single core (current setup) on a 2 core system 0.0.0.0/1 would be managed by RDE0 128.0.0.0/1 would be managed by RDE1 on a 4 core system 0.0.0.0/2 RDE0 64.0.0.0/2 RDE1 128.0.0.0/2 RDE2 192.0.0.0/2 RDE3 on an 8 core system 0.0.0.0/3 RDE0 32.0.0.0/3 RDE1 64.0.0.0/3 RDE2 96.0.0.0/3 RDE3 128.0.0.0/3 RDE4 160.0.0.0/3 RDE5 192.0.0.0/3 RDE6 224.0.0.0/3 RDE7 ???? you can use the spare cycles on this one to generate your favourite concurrency or help SETI :P or something :) so each process may not be equally loaded but they would be faster over all with the increased parallelism ... and because each RDE is operating on prefixes that are only in a certain range that doesn't overlap other RDE Process work ... there would never be a race condition or nasty MP introduced bugs also there would need to be some work on the session engine to pass theBGP messages to the correct RDE process easily (the decision process would be similar to a routing decision in the kernel LPM with 2 or 4 or 8 routes ) IPv6 I get would need a more nuanced approach as in split the subset 2000::/3 as opposed to 0:0/128 It would be a long time before I would be able to submit a patch worthy of consideration... but is this Idea worth pursuing ? is there a fundamental flaw in this idea / approach Thanks for your time and consideration... Tom Smyth
