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

Maxime Leroy
2026-03-23T11:27:17Z

Hi Vladimir,

On Sun, Mar 22, 2026 at 4:42 PM Vladimir Medvedkin
<vladimir.medvedkin@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.
>

Thanks for the RFC. Some thoughts below.

Memory cost: the flat TBL24 replicates the entire table for every VRF
(num_vrfs * 2^24 * nh_size). With 256 VRFs and 8B nexthops that is
32 GB for TBL24 alone. In grout we support up to 256 VRFs allocated
on demand -- this approach forces the full cost upfront even if most
VRFs are empty.

Per-packet VRF lookup: Rx bursts come from one port, thus one VRF.
Mixed-VRF bulk lookups do not occur in practice. The three AVX512
code paths add complexity for a scenario that does not exist, at
least for a classic router. Am I missing a use-case?

I am not too familiar with DPDK FIB internals, but would it be
possible to keep a separate TBL24 per VRF and only share the TBL8
pool? Something like pre-allocating an array of max_vrfs TBL24
pointers, allocating each TBL24 on demand at VRF add time, and
having them all point into a shared TBL8 pool. The TBL8 index in
TBL24 entries seems to already be global, so would that work without
encoding changes?

Going further: could the same idea extend to IPv6? The dir24_8 and
trie seem to use the same TBL8 block format (256 entries, same
(nh << 1) | ext_bit encoding, same size). Would unifying the TBL8
allocator allow a single pool shared across IPv4, IPv6, and all
VRFs? That could be a bigger win for /32-heavy and /128-heavy tables
and maybe a good first step before multi-VRF.

Regards,

Maxime Leroy

> 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(-)
>
> --
> 2.43.0
>

--
-------------------------------
Maxime Leroy
maxime@leroys.fr