[RFC PATCH 0/4] VRF support in FIB library

[Medvedkin, Vladimir]

Hi Stephen,

On 3/22/2026 4:43 PM, Stephen Hemminger wrote:
> On Sun, 22 Mar 2026 15:42:11 +0000
> Vladimir Medvedkin <vladimir.medvedkin at intel.com> wrote:
>
>> This series adds multi-VRF support to both IPv4 and IPv6 FIB paths by
>> allowing a single FIB instance to host multiple isolated routing domains.
>>
>> Currently FIB instance represents one routing instance. For workloads that
>> need multiple VRFs, the only option is to create multiple FIB objects. In a
>> burst oriented datapath, packets in the same batch can belong to different VRFs, so
>> the application either does per-packet lookup in different FIB instances or
>> regroups packets by VRF before lookup. Both approaches are expensive.
>>
>> To remove that cost, this series keeps all VRFs inside one FIB instance and
>> extends lookup input with per-packet VRF IDs.
>>
>> The design follows the existing fast-path structure for both families. IPv4 and
>> IPv6 use multi-ary trees with a 2^24 associativity on a first level (tbl24). The
>> first-level table scales per configured VRF. This increases memory usage, but
>> keeps performance and lookup complexity on par with non-VRF implementation.
>>
>> Vladimir Medvedkin (4):
>>    fib: add multi-VRF support
>>    fib: add VRF functional and unit tests
>>    fib6: add multi-VRF support
>>    fib6: add VRF functional and unit tests
>>
>>   app/test-fib/main.c      | 257 ++++++++++++++++++++++--
>>   app/test/test_fib.c      | 298 +++++++++++++++++++++++++++
>>   app/test/test_fib6.c     | 319 ++++++++++++++++++++++++++++-
>>   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 ++++++++-
>>   lib/fib/rte_fib6.c       | 166 +++++++++++++---
>>   lib/fib/rte_fib6.h       |  88 +++++++-
>>   lib/fib/trie.c           | 158 +++++++++++----
>>   lib/fib/trie.h           |  51 +++--
>>   lib/fib/trie_avx512.c    | 225 +++++++++++++++++++--
>>   lib/fib/trie_avx512.h    |  39 +++-
>>   15 files changed, 2453 insertions(+), 396 deletions(-)
>
> Not sure at all if this the right way to do VRF.
I'd like to hear the reason why this is not the right way, what is the 
right way and why
> There are multiple ways to do VRF, the Linux way, the Cisco way, ...

I'm not 100% sure what defines a "way", but looking at VPP (since Cisco 
was mentioned) their way is pretty much the same as Linux - i.e. it has 
a separate handle per VRF(fib_index):

https://github.com/FDio/vpp/blob/c2f6a88b43d6175730d5d19364cb446e128065da/src/vnet/fib/ip4_fib.h#L128

In grout with the current FIB design the situation is the same - FIB 
instance per VRF(vrf_id):

https://github.com/DPDK/grout/blob/0f7b91c287f7f54cd75a1b64da7ade505b346bf5/modules/ip/control/route.c#L147

I wrote about the problems of this approach in the cover letter, 
different options were considered, and this is the design I have arrived at.

After all, why should we have to follow someone else's way? I'm 
proposing our own "DPDK way" :)

>
>
>
> This needs way more documentation and also an example.
> Like an option to l3fwd. And also an implementation in testpmd.

-- 
Regards,
Vladimir