option FIB_ALGO and dpdk_lpm4

[Marek Zarychta]

>  
> Btw, have you seen any notable dataplane/control plane performance
> difference w/ FIB_ALGO ?

Dear Alexander, valued subscribers,

at last, I have upgraded our BGP router running two instances of
net/bird (IP and IPv6) from 11.4-STABLE  to 13.0-STABLE just on time to
catch the "Fix nd6 rib_action() handling". The performance boost is
really impressive, but probably not only FIB_ALGO is responsible for it
since there were also improvements in PF, lagg(4), aggregated  NICs
utilize now iflib and so on. Getting to the point: now when the links
are saturated with normal traffic the load on this 8 core ATOM dropped
from ~3.5 to ~0.9. The pmc(3) has changed a bit over time and now with
PMC: [cpu_clk_unhalted.ref] I get max 1.5% for  rn_match function, but
the caller is always pfr_match_addr, so it comes likely from PF. In
11.4  rn_match was peaking up to  9% with links saturated with normal
traffic but there were more callers: fib6_lookup_nh_basic:4.2
pfr_match_addr:1.4 fib4_lookup_nh_basic:1.4. Now only occasionally I
observe function  rn_walktree peaking up to ~20% called by rib_walk what
probably comes from net/bird adding/removing routes. At this stage
(updating routes) on 11.x-STABLE bird seemed to block/stale the ability
to interact with the system for a fraction of second. Now all updates go
smooth.

So congrats, an excellent job was done, thank you very much for this
effort and time spent on making this all happen.

Please let me ask only one final question. Does adding:

net.route.algo.inet.algo=dpdk_lpm4
net.route.algo.inet6.algo=dpdk_lpm6

to /etc/sysctl.conf make any sense?  I see that right FIB_ALGO is
automatically picked up when the module is available.

After first reboot into 13-STABLE:

Feb 23 22:42:10 rtr kernel: [fib_algo] fib_module_register: attaching
radix6_lockless to inet6
Feb 23 22:42:10 rtr kernel: [fib_algo] fib_module_register: attaching
radix6 to inet6
Feb 23 22:42:10 rtr kernel: [fib_algo] fib_module_register: attaching
bsearch4 to inet
Feb 23 22:42:10 rtr kernel: [fib_algo] fib_module_register: attaching
radix4_lockless to inet
Feb 23 22:42:10 rtr kernel: [fib_algo] fib_module_register: attaching
radix4 to inet
Feb 23 22:42:10 rtr kernel: [33] [fib_algo] fib_module_register:
attaching dpdk_lpm6 to inet6
Feb 23 22:42:10 rtr kernel: [33] [fib_algo] fib_module_register:
attaching dpdk_lpm4 to inet
Feb 23 22:42:10 rtr kernel: [43] [fib_algo] inet.0 (bsearch4#66)
rebuild_fd: switching algo to radix4_lockless
Feb 23 22:42:10 rtr kernel: [49] [fib_algo] inet.1 (bsearch4#67)
rebuild_fd: switching algo to radix4_lockless
Feb 23 22:42:39 rtr kernel: [80] [fib_algo] inet.0 (radix4_lockless#650)
rebuild_fd: switching algo to dpdk_lpm4
Feb 23 22:42:42 rtr kernel: [83] [fib_algo] inet6.0
(radix6_lockless#705) rebuild_fd: switching algo to dpdk_lpm6

Though after second reboot with "Fix nd6 rib_action() handling" applied
there is no "switching algo to dpdk_lpm6":

Feb 23 23:55:24 rtr kernel: [fib_algo] fib_module_register: attaching
radix6_lockless to inet6
Feb 23 23:55:24 rtr kernel: [fib_algo] fib_module_register: attaching
radix6 to inet6
Feb 23 23:55:24 rtr kernel: [fib_algo] fib_module_register: attaching
bsearch4 to inet
Feb 23 23:55:24 rtr kernel: [fib_algo] fib_module_register: attaching
radix4_lockless to inet
Feb 23 23:55:24 rtr kernel: [fib_algo] fib_module_register: attaching
radix4 to inet
Feb 23 23:55:24 rtr kernel: [10] [fib_algo] fib_module_register:
attaching dpdk_lpm6 to inet6
Feb 23 23:55:24 rtr kernel: [10] [fib_algo] fib_module_register:
attaching dpdk_lpm4 to inet
Feb 23 23:55:24 rtr kernel: [20] [fib_algo] inet.0 (bsearch4#66)
rebuild_fd: switching algo to radix4_lockless
Feb 23 23:55:24 rtr kernel: [26] [fib_algo] inet.1 (bsearch4#67)
rebuild_fd: switching algo to radix4_lockless
Feb 23 23:55:57 rtr kernel: [61] [fib_algo] inet.0 (radix4_lockless#571)
rebuild_fd: switching algo to dpdk_lpm4

Should I be bothered about it?

With kind regards,

-- 
Marek Zarychta