<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">When a BGP sessions comes up/down, there is a period of high CPU while all the new best-routes are computed -- this is understandable.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">However, on boxes I have where this table is then promoted to the Linux kernel, the CPU usage stays high for some considerable time. For a full (~600,000 prefix) </div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">From the looks of things, a bunch of netlink messages are being generated to the kernel to RTM_DELROUTE then RTM_NEWROUTE -- each of which is causing the kernel's trie to rebalance which is a fairly costly operation.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">I was wondering if anyone had experimented with anything such as implementing either:</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">1. a corking mechanism (i.e. stop balancing the trie until a signal is sent to uncork)</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">2. fib_trie garbage collection (i.e. only rebalance the trie once per time interval)</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">3. "double buffering" (i.e. for a given operation such as protocol flap, memcpy the trie, perform operations, then update the root node pointer to the new optimised trie)</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Any and all of these ideas may be horrific, I'm just interested whether anyone's running full tables in linux, filled by (e.g.) BIRD, and have encountered this issue.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Unfortunately there doesn't appear to be an RTM_CHANGE or similar in Linux, so the DELROUTE will seemingly cause a tree to either be pruned or re-branched, followed by the NEWROUTE causing a full rebalance run -- whereas a CHANGE would (could) hopefully just over-write the value.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Many thanks in advance,</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Matthew Walster</div></div>