[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd18410f-7065-ebea-74c5-4c016a3f1436@gmail.com>
Date: Tue, 18 Feb 2020 18:05:58 -0700
From: David Ahern <dsahern@...il.com>
To: Carmine Scarpitta <carmine.scarpitta@...roma2.it>
Cc: davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
kuba@...nel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, ahmed.abdelsalam@...i.it,
dav.lebrun@...il.com, andrea.mayer@...roma2.it,
paolo.lungaroni@...t.it
Subject: Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table
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?
Powered by blists - more mailing lists