[Xorp-hackers] XRL performance

[Ben Greear]

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.

[root at 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 <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com