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

[Carmine Scarpitta]

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. 

Thanks,
Carmine


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>