W dniu 08.02.2021 o 13:10, mike tancsa pisze: > I have been setting up some tests to see if > > option FIB_ALGO and dpdk_lpm4.ko > > will help with my pkt forwarding needs and large routing tables. So far so > good. But one thing I noticed, is that its very chatty to dmesg. > eg > alloc_nhgrp: new mpath group: num_nhops: 2 > compile_nhgrp: O: 2/2 > compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 > compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 > alloc_nhgrp: new mpath group: num_nhops: 2 > compile_nhgrp: O: 2/2 > compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 > compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 > alloc_nhgrp: new mpath group: num_nhops: 2 > compile_nhgrp: O: 2/2 > compile_nhgrp: OO[0]: 1/1 curr=1 slot_idx=0 > compile_nhgrp: OO[1]: 0/0 curr=1 slot_idx=1 > > are these debugging messages that forgot to be turned off ? What do they > mean ? > Thanks for this work! > > 13.0-STABLE #11 stable/13-cc1352c1f-dirty >
Thank you for sharing this Mike. Could you please reveal us how do you
feed your routing tables? Is net/bird{,2} or net/frr7 involved? Any
problems or hints to make the routing daemon working with new routing stack?
The new routing stack looks very promising, please let me also give this
way some appreciations to melifaro@ and other people who worked on it.
I was also trying to test it with legacy net/bird and multiple fib
tables, but I was early hit by: "KRT: Error sending route x.x.x.x/y to
kernel: Operation not supported"
Setting net.add_net.add_addr_allfibs=1addr_allfibs=1 changed it a bit,
but still some blackhole /32 routes seem to get rejected.
--
Marek Zarychta
OpenPGP_signature
Description: OpenPGP digital signature
