Here are some of Marko's thoughts on the subject.
Includes a (still working) link to a patch against XORP (at that time)
which implements batch XRL updates.
A similar change exists in the corporate version of XORP.
--- Begin Message ---
On Friday 05 September 2008 14:28:12 Orion T Hodson wrote:
...
> AFAIK, the default transport pipelines requests and the binary
> encoding is about as trivial as it can be. It'd be good to verify
> this is the case and how well it works.
...
> Some of the consumers of the XRL interface could be modified to
> make few XRL calls, e.g. routing table operations used to be
> individual XRL calls add_route, delete_route, etc, but would make
> more efficient use of resources if batched up into groups with a
> single route_updates(...) XRL.
I did an experiment encoding route add/delete requests in binary form
and batching a few of those in a single XRL as binary atoms, and the
performance improvement was quite observable. The results represent
per-process (BGP, RIB, FEA) and cumulative time spent in an idle stub
XORP instance syncing with the ICSI BGP feed of two and something years
ago:
Standard CVS code, 190 K prefix feed flap:
BGP 27s RIB 22s FEA 16s Total 65s
Binary encoding ~110 adds per single XRL, 190 K prefix feed flap:
BGP 16s RIB 2s FEA 8s Total 26s
Observe that the time spent in RIB went down by 90% down to only 2s for
a full feed flap. I didn't produce a productionworthy patch but only
played with teh XRL binary encoding + route add/del request batching to
get a feeling for the performance improvement potential. THe only
patch I could find from that time is here:
http://imunes.net/perf-rib-fea-diff3
it was unreliable but managed to get most of the 190k routes from BGP
down to the kernel (FreeBSD 4.11 at that time) in the above timeframe.
Anyhow, my interpretation of that experiment is that XRL performance
probably wouldn't get much better solely by switching to shared memory
XRL transport. My deeper profiling attempts of the day, aimed at
finding out the true cause of XRL encoding/decoding pathetic slowness,
were a total failure OTOH :(
Cheers,
MArko
_______________________________________________
Xorp-dev mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-dev
--- End Message ---
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
