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

Medvedkin, Vladimir
2026-03-25T14:10:08Z

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@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