[RFC PATCH 1/4] fib: add multi-VRF support

[Medvedkin, Vladimir]

On 3/23/2026 10:22 PM, Konstantin Ananyev wrote:
>>>> Add VRF (Virtual Routing and Forwarding) support to the IPv4
>>>> FIB library, allowing multiple independent routing tables
>>>> within a single FIB instance.
>>>>
>>>> Introduce max_vrfs and vrf_default_nh fields in rte_fib_conf
>>>> to configure the number of VRFs and per-VRF default nexthops.
>>> Thanks Vladimir, allowing multiple VRFs per same LPM table will
>>> definitely be a useful thing to have.
>>> Though, I have the same concern as Maxime:
>>> memory requirements are just overwhelming.
>>> Stupid q - why just not to store a pointer to a vector of next-hops
>>> within the table entry?
>> Am I understand correctly, a vector with max_number_of_vrfs entries and
>> use vrf id to address a nexthop?
> Yes.

Here I can see 2 problems:

1. tbl entries must be the size of a pointer, so no way to use smaller sizes

2. those vectors will be sparsely populated and, depending on the 
runtime configuration, may consume a lot of memory too (as Robin 
mentioned they may have 1024 VRFs)

>
>> Yes, this may work.
>> But, if we are going to do an extra memory access, I'd better to
>> maintain an internal hash table with 5 byte keys {24_bits_from_LPM,
>> 16_bits_vrf_id} to retrieve a nexthop.
> Hmm... and what to do with entries in tbl8, I mean what will be the key for them?
> Or you don't plan to put entries from tbl8 to that hash table?

The idea is to have a single LPM struct with a join superset of all 
prefixes existing in all VRFs. Each prefix in this LPM struct has its 
own unique "nexthop", which is not the final next hop, but an 
intermediate metadata defining this unique prefix. Then, the following 
search is performed with the key containing this intermediate metadata + 
vrf_id in some exact match database like hash table. This approach is 
the most memory friendly, since there is only one LPM data struct (which 
scales well with number of prefixes it has) with intermediate entries 
only 4b long.
On the other hand it requires an extra search, so lookup will be slower. 
Also, some current LPM optimizations, like tbl8 collapsing if all tbl8 
entries have a similar value, will be gone.


>
>>> And we can provide to the user with ability to specify custom
>>> alloc/free function for these vectors.
>>> That would help to avoid allocating huge chunks of memory at startup.
>>> I understand that it will be one extra memory dereference,
>>> but probably it will be not that critical in terms of performance .
>>> Again for bulk function  we might be able to pipeline lookups and
>>> de-references and hide that extra load latency.
>>>
>>>> Add four new experimental APIs:
>>>> - rte_fib_vrf_add() and rte_fib_vrf_delete() to manage routes
>>>>     per VRF
>>>> - rte_fib_vrf_lookup_bulk() for multi-VRF bulk lookups
>>>> - rte_fib_vrf_get_rib() to retrieve a per-VRF RIB handle
>>>>
>>>> Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin at intel.com>
>>>> ---
>>>>    lib/fib/dir24_8.c        | 241 ++++++++++++++++------
>>>>    lib/fib/dir24_8.h        | 255 ++++++++++++++++--------
>>>>    lib/fib/dir24_8_avx512.c | 420 +++++++++++++++++++++++++++++++--------
>>>>    lib/fib/dir24_8_avx512.h |  80 +++++++-
>>>>    lib/fib/rte_fib.c        | 158 ++++++++++++---
>>>>    lib/fib/rte_fib.h        |  94 ++++++++-
>>>>    6 files changed, 988 insertions(+), 260 deletions(-)
>>>>
>> <snip>
>>
>> --
>> Regards,
>> Vladimir
>>
-- 
Regards,
Vladimir