Hi Robin,
Apologies for the delayed response
On 19/03/2024 20:38, Robin Jarry wrote:
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.
IfindthismoreconvenientfordataplanestructureslikeDIR24-8,whereIneedto
findgaps forsomegivensuperprefix.
> 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.
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.
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
