After some prodding from Bruce I took a closer look at xrl and noticed that it used new/delete for each xrl_atom for things like IPv4 addresses, macs, etc.
As a proof of concept, I moved IPv4 and IPv4Net object types directly into the xrl atom class instead of using new/delete. This uses an extra 12 bytes per XRL atom, but I think that is a good trade-off to remove the new/delete logic. I also got the libxipc test logic working again (it had been broken in xorp.ct for some months due to a bad merge I did..not sure if it works in upstream or not) and tweaked the sender to allow sending different XRL types. These changes have just been pushed to xorp.ct On my test machine (3.3Ghz quad-core i&), I see this performance when sending the 'large' xrl. It's maybe a bit better than before my changes, but normally it bouches around quite a lot, so it's hard to benchmark small improvements. [r...@ct503-10g-09 tests]# ./test_xrl_sender -s 2 -N 500000 XrlAtoms per call = 1 Send method = pipeline Send style = 2 start_transmission_cb 100 Okay Received 500000 XRLs; delta_time = 4.212246 secs; speed = 118701.519332 XRLs/s start_transmission_cb 100 Okay Received 500000 XRLs; delta_time = 4.498949 secs; speed = 111137.067791 XRLs/s start_transmission_cb 100 Okay Received 500000 XRLs; delta_time = 4.079798 secs; speed = 122555.087286 XRLs/s start_transmission_cb 100 Okay Received 500000 XRLs; delta_time = 4.071571 secs; speed = 122802.721603 XRLs/s start_transmission_cb 100 Okay There is certainly more to optimize in xrl logic, including moving such things as MACs inline like I did for ipv4 and probably encoding them in 6 binary bytes instead of ascii (as it appears to do now). But, at over 100,000 XRLs per second, it's reasonably fast as is. I hear bgp has issues with large route databases, so I'm going to attempt to find some way to reproduce that and debug it directly. My guess is that the root cause is not directly related to XRL/s but probably a lack of batching or some other similar issue. Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
