On Wed, 2021-06-23 at 22:37 +0200, Olivier Cochard-Labbé wrote: > > FreeBSD includes now multiple route lookup algorithms [1]: > - bsearch: Binary search used if less than 16 routes installed; > - radix_lockless: selected if you have more than 16 but less than 1000 > routes installed; > - radix: radix (compressed binary tree), the default one used as > fallback > - dpdk_lpm: DPDK RTE Longuest Prefix Match (need to load kernel > modules: dpdk_lpm4.ko and dpdk_lpm6.ko, which is done on BSDRP) > - dxr: very fast IPv4 LPM (need to load kernel module: fib_dxr.ko) > > Currently you are using the dpdk algo, but could you revert back to the > historical default (radix) to check if it solves your problem ? > You could try a : > sysctl net.route.algo.inet.algo=radix4
Thank you, that did the trick:
[root@amarklor]/etc# traceroute -n 51.15.183.144
traceroute to 51.15.183.144 (51.15.183.144), 64 hops max, 40 byte
packets
1 149.6.174.241 0.882 ms 0.502 ms 0.508 ms
2 154.25.12.205 1.242 ms
149.6.174.241 as a first hop reflects the kernel routing-table.
CPU-Usage increased by about the factor of 3, but no Core runs over
10% usage, such quite some headroom here.
Seems that the dpdk forwarder needs some work. But you also
mentioned dxr. I remember that from over a decade ago, It
was pretty impressive performance-wise. Any caveats here?
More spefically: why does BSDRP prefer dpdk over dxr? The
latter has adjustable Lookup-Table mask-lenghts, and the
/24 in dpdk seem a little bit over-the-top (yes, there are
tons ov /24, but these /24 are usually from Network operators
without clue (if not from the old historic swamp-space).
Networks with sufficiently high bandwidth / pps demands are rarely
more precise than a /20; so to be on the safe side going with a
/21 or /22 Table-Index should yield good results.
cu
Clemens.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Bsdrp-users mailing list Bsdrp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bsdrp-users
