Hi Robin,
Apologies for the delayed response
Hi Vladimir,
Medvedkin, Vladimir, Mar 19, 2024 at 18:16:
> 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.
OK that's good to know, thanks.
> 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:
I had tried it and got confusing results out of this. This must have been before I had realized that all addresses needed to be in host order...
I tried again and it works as advertised with a small missing detail: after configuring a default route, e.g.:
rte_fib_add(fib, RTE_IPV4(2, 2, 0, 0), 16, RTE_IPV4(1, 2, 3, 4));
rte_fib_add(fib, RTE_IPV4(3, 3, 3, 0), 24, RTE_IPV4(4, 3, 2, 1));
rte_fib_add(fib, RTE_IPV4(0, 0, 0, 0), 0, RTE_IPV4(9, 9, 9, 9));
It is not returned by rte_rib_get_nxt() successive calls. I only see the other two routes:
2.2.0.0/16 via 1.2.3.4
3.3.3.0/24 via 4.3.2.1
Is this expected?
Yes, it is expected. It is also reflected in API: "Retrieve next more specific prefix ...". So, in your case you should explicitly lookup 0/0 route.
I find this more convenient for data plane structures like DIR24-8, where I need to find gaps for some given superprefix.
I just implemented lookup the same way as LPM. As for valid scenario, years ago I used an LPM/FIB lookup on a huge text log file(it was nginx logs if I remember correctly) with hundreds of million lines with IP addresses to resolve corresponding AS numbers for some statistics. The macro I used converted substrings with IPv4 into unsigned integers in host byte order. So, it is not always true that IPv4 are in network byte order.
> 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.
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.
This should really be advertised in strong capital letters in the API docs. Or (preferably) hidden to the user. I don't see any valid scenario where you would work with host order IPv4 addresses.
Do you think we could change that API or at least add a flag at FIB/RIB creation to make it transparent to the user and consistent between IPv4 and IPv6?
Yes, I will add FIB configuration option to allow BE IPv4 as an input for lookup function.
Thanks!
-- Regards, Vladimir