Hi Stephen,
On 3/22/2026 4:43 PM, Stephen Hemminger wrote:
On Sun, 22 Mar 2026 15:42:11 +0000
Vladimir Medvedkin <[email protected]> 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
