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 ---Mike
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20210208/12645530/attachment.sig>
08.02.2021, 12:10, "mike tancsa" <mike at sentex.net>:> 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 ?Yep, these are the remnants of early-day debugging. I'll remove them this week.> Thanks for this work! > > 13.0-STABLE #11 stable/13-cc1352c1f-dirty > > ????????---Mike > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"