freebsd stable - Feb 2021 - option FIB_ALGO and dpdk_lpm4

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, 14:33, "Marek Zarychta" <zarychtam at
plan-b.pwste.edu.pl>:
> 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?
Non-multipath should work as before, multipath works for quagga/frr but needs
some patches for bird.
>
> 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"
Any chance you could clarify what are these routes? "Operation not
supported" looks a bit weird, it shouln't
happen.
> Setting net.add_net.add_addr_allfibs=1addr_allfibs=1 changed it a bit,
> but still some blackhole /32 routes seem to get rejected.
Just "blackhole" route in the bird config? /32 or
all?
>
> --
> Marek Zarychta