Re: fib{,6}: questions and proposals

["Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>]

Hi Robin,

On 19/03/2024 08:30, Robin Jarry wrote:
> Hi Vladimir,
>
> I have been using rte_fib for a while and stumbled upon a few quirks. 
> I was wondering if you would answer some questions:
>
> 1) Is it OK/safe to share the same fib to perform route lookups from   
> multiple lcores in parallel? So far my observations seem to validate   
> that assumption but I would like your opinion :)
Yes, 100% :)
>
> 2) Is it OK/safe to modify a fib from a control thread (read/write)   
> while it is used by data path threads (read only)?

This part is a bit more complicated. In practice, I would say yes, 
however, there is a possibility that if the lookup thread is preempted 
in the middle of the lookup process, and at the same time the control 
thread deletes the corresponding route, then the lookup result may 
return outdated data. This problem is solved in LPM with RCU enabled. I 
have plans to implement it in the near future in the FIB.

>
> 3) There is no public API to list/walk all configured routes in a fib. 
>   Would that be possible/easy to implement?

Yes, it already there. FIB under the hood uses rte_rib to hold existing 
routes. So walking through can be implemented like:

struct rte_fib fib;

....

struct rte_rib rib = rte_fib_get_rib(fib);

struct rte_rib_node *cur = NULL;

do {

cur = rte_rib_get_nxt(rib, RTE_IPV4(0,0,0,0) /*this is supernet where 
you'd like to iterate*/, 0 /*and this is depth*/, cur, RTE_RIB_GET_NXT_ALL);

if (cur)

     printf...

} while (cur)


>
> 4) In rte_fib, every IPv4 address (route *and* next hop) needs to be 
> in   host order. This is not consistent with fib6 where addresses are 
>   stored in network order. It took me quite a while to figure out what 
>   was wrong with my code.
>
>   I assume this is because DIR24 needs host order integers and not   
> TRIE. Why was this not hidden in the API?
>
>   Could we add a flag to rte_fib_conf to change the behaviour? This   
> would avoid error prone ntohl/htonl juggling.

This API behavior was created in such a way that it is the same as LPM.

As for LPM, I think it was done this way for performance reasons because 
in some scenarios you only working with the host order ipv4 addresses.

>
> Thanks in advance for your replies :)
>
-- 
Regards,
Vladimir