[Xorp-cvs] XORP cvs commit: xorp/bgp xorp/policy/backend xorp/policy/common
Andrea Bittau
abittau at icir.org
Wed Aug 6 01:07:15 PDT 2008
CVSROOT: /usr/local/www/data/cvs
Module name: xorp
Changes by: abittau at chum.icir.org 2008-08-06 08:07:15 UTC
XORP CVS repository
Modified files:
bgp route_table_policy.cc
policy/backend backend.l backend.y iv_exec.cc iv_exec.hh
lex.yy_policy_backend_parser.cc
policy_backend_parser.hh policy_filter.cc
policy_instr.hh policy_profiler.cc
yacc.yy_policy_backend_parser.cc
policy/common varrw.cc varrw.hh
Log message:
The policy "trace" option was implemented poorly. A trace would always be
produced, and then printed out only if needed. This slowed things down
immensly. I now pre-generate the trace only for policies that have trace
enabled. In other words, if you have trace on for a policy, the router will run
like a dog.
BGP was aware of this and had a fix which I removed. The fix was more efficient
than what I currently do since it would re-run the policy with trace on for only
the routes that mached. Instead, I trace for all routes (if trace is on). In
any event, the BGP fix was more of a hack and the policy engine should deal with
this issue internally. Perhaps we gotta decide what to do about this. We can
either:
1) Document and say: "If you enable trace, you'll be slow".
2) Have more efficient tracing, e.g., binary format, or less verbose. Then
convert to text only if needed.
3) Do like BGP did - rerun filter on a match to produce a trace.
Anyway, the behavior for now is basically: fast with no trace, slow with trace,
which is probably OK for the time being. Once we converge on a solution, I'll
implement it inside the policy framework.
Here was the policy speed this morning:
[81% shorty test]# ./policybench -p base -v base.var
Loading...
Benchmarking. Iterations: 10000
Stats:
Total time 702 (ms) iterations 10000
Iterations/s 14245.014
Instr 1 Avg Time 8594.352 ( 8.42%)
Instr 2 Avg Time 15842.157 (15.52%)
Instr 3 Avg Time 2126.646 ( 2.08%)
Instr 4 Avg Time 1466.712 ( 1.44%)
Instr 5 Avg Time 18572.303 (18.20%)
Instr 6 Avg Time 6439.466 ( 6.31%)
Instr 7 Avg Time 5396.425 ( 5.29%)
Instr 8 Avg Time 26569.690 (26.03%)
Instr 9 Avg Time 6240.700 ( 6.11%)
Instr 10 Avg Time 10808.420 (10.59%)
[82% shorty test]#
Here's the speed now:
[100% shorty test]# ./policybench -p base -v base.var
Loading...
Benchmarking. Iterations: 10000
Stats:
Total time 94 (ms) iterations 10000
Iterations/s 106382.979
Instr 1 Avg Time 181.737 ( 2.25%)
Instr 2 Avg Time 604.821 ( 7.48%)
Instr 3 Avg Time 934.825 (11.56%)
Instr 4 Avg Time 337.907 ( 4.18%)
Instr 5 Avg Time 696.474 ( 8.61%)
Instr 6 Avg Time 220.004 ( 2.72%)
Instr 7 Avg Time 3114.679 (38.52%)
Instr 8 Avg Time 668.780 ( 8.27%)
Instr 9 Avg Time 223.682 ( 2.77%)
Instr 10 Avg Time 1102.328 (13.63%)
[100% shorty test]#
7x faster (14k routes/s -> 100k routes/s)
Revision Changes Path
1.26 +1 -12; commitid: 828c48995b9e41a7; xorp/bgp/route_table_policy.cc
1.9 +11 -11; commitid: 828c48995b9e41a7; xorp/policy/backend/backend.l
1.12 +12 -0; commitid: 828c48995b9e41a7; xorp/policy/backend/backend.y
1.19 +29 -25; commitid: 828c48995b9e41a7; xorp/policy/backend/iv_exec.cc
1.14 +3 -1; commitid: 828c48995b9e41a7; xorp/policy/backend/iv_exec.hh
1.10 +16 -16; commitid: 828c48995b9e41a7; xorp/policy/backend/lex.yy_policy_backend_parser.cc
1.7 +2 -7; commitid: 828c48995b9e41a7; xorp/policy/backend/policy_backend_parser.hh
1.16 +2 -2; commitid: 828c48995b9e41a7; xorp/policy/backend/policy_filter.cc
1.9 +9 -5; commitid: 828c48995b9e41a7; xorp/policy/backend/policy_instr.hh
1.3 +1 -5; commitid: 828c48995b9e41a7; xorp/policy/backend/policy_profiler.cc
1.12 +46 -31; commitid: 828c48995b9e41a7; xorp/policy/backend/yacc.yy_policy_backend_parser.cc
1.11 +16 -8; commitid: 828c48995b9e41a7; xorp/policy/common/varrw.cc
1.16 +6 -13; commitid: 828c48995b9e41a7; xorp/policy/common/varrw.hh
More information about the Xorp-cvs
mailing list