Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

From: Carmine Scarpitta
Date: Tue Feb 18 2020 - 21:50:24 EST

Hi David,
Thanks for the reply.

The problem is not related to the table lookup. Calling fib_table_lookup and then rt_dst_alloc from seg6_local.c is good.

But after the lookup we need to forward the packet according the matched table entry. This requires to perform all the steps already implemented by ip_route_input_slow function. So we need to call the following functions (defined in route.c):
- rt_cache_valid
- find_exception
- rt_dst_alloc
- rt_set_nexthop
- rt_cache_route

Some of these functions are not exported and so we cannot call them from seg6_local.c
Consequently, we are not able to support all the functionalities implemented by IPv4 routing subsystem.

We are not harming the IPv4 FIB lookup. We introduce a new flag that allows us to re-use all the non exported functions.

If the flag is not set, the normal IPv4 FIB lookup is the same with no change.


On Tue, 18 Feb 2020 18:05:58 -0700
David Ahern <dsahern@xxxxxxxxx> wrote:

> On 2/18/20 4:50 PM, Carmine Scarpitta wrote:
> > Indeed both call fib_table_lookup and rt_dst_alloc are exported for modules.
> > However, several functions defined in route.c are not exported:
> > - the two functions rt_cache_valid and rt_cache_route required to handle the routing cache
> > - find_exception, required to support fib exceptions.
> > This would require duplicating a lot of the IPv4 routing code.
> > The reason behind this change is really to reuse the IPv4 routing code instead of doing a duplication.
> >
> > For the fi member of the struct fib_result, we will fix it by initializing before "if (!tbl_known)"
> The route.c code does not need to know about the fib table or fib
> policy. Why do all of the existing policy options (mark, L3 domains,
> uid) to direct the lookup to the table of interest not work for this use
> case?

Carmine Scarpitta <carmine.scarpitta@xxxxxxxxxxx>