Hi Maxime, Thanks for working on this RFC. I have mixed feelings about the series. Here some conceptual thoughts:
On the positive side, I like the consolidation of the common tbl8 code between the ipv4 dir24_8 and ipv6 trie implementations. Removing duplicated code is always good. General approach to the implementation is good too, no extra indirection for TBL8 on lookup, backward compatibility with the current "legacy" way to allocate tbl8 (although needs to carefully zero-init config). However, I have concerns about both the scope of the public API and the resizing implementation. First, I am not yet convinced that this feature belongs in the public FIB API, TBL8 is an implementation detail of the currently supported dir24_8 and trie backends. This series exposes part of internal algorithms to a public as a generic FIB resource, although a future FIB algorithm may have nothing to do with 8-bit stride trie level. As discussed in the other thread, the main use case appears to be sharing tbl8 capacity between many VRFs represented by separate FIB instances. In my view, separate FIB instance per VRF is not necessarily the best design. A shared TBL8 pool mitigates part of a problem, but does not solve the problem entirely. I understand that the previous RFC for multiVRF support in FIB, while having shared TBL8 internally, have problems with high memory consumption. I am currently working on v2, so I suggest returning to the shared pool discussion after that series is available. So, on one hand, it addresses a real use case, and a useful feature should not be rejected merely because it initially has only one known user. On the other hand, if the feature remains specific to a single application, the additional API and implementation complexity will be carried by the library and exposed to every FIB user. It may also make the API more difficult to understand by presenting TBL8 pools as a general FIB concept. Maybe, if we decide to add this after multi VRF rework, it is worth to add this as an internal API (not as a generic FIB API)? I'd like to hear more opinions on this. Second, regarding resizing, I don't think the current implementation is applicable. For example, build_common_root() computes tbl_ptr from its local cur_tbl. After the first level, cur_tbl can point into the current tbl8. A subsequent tbl8_alloc() may resize the pool, publish the new base, wait for an RCU grace period, and free the old allocation. Control then returns to build_common_root(), which writes through the old tbl_ptr. Same problem exists in other places like in write_edge(). I'm also not convinced in grow-only resizing without shrinking. -----Original Message----- From: Maxime Leroy <[email protected]> Sent: Thursday, July 16, 2026 8:31 AM To: Medvedkin, Vladimir <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [RFC 0/5] fib: shared and resizable tbl8 pool Hi Vladimir, On Tue, Mar 31, 2026 at 11:41 PM Maxime Leroy <[email protected]> wrote: > > This RFC proposes an optional shared tbl8 pool for FIB/FIB6, to > address the difficulty of sizing num_tbl8 upfront. > > In practice, tbl8 usage depends on prefix distribution and evolves > over time. In multi-VRF environments, some VRFs are elephants (full > table, thousands of tbl8 groups) while others consume very little > (mostly /24 or shorter). Per-FIB sizing forces each instance to > provision for its worst case, leading to significant memory waste. > > A shared pool solves this: all FIBs draw from the same tbl8 memory, so > elephant VRFs use what they need while light VRFs cost almost nothing. > The sharing granularity is flexible: one pool per VRF, per address > family, a global pool, or no sharing at all. > > This series adds: > > - A shared tbl8 pool, replacing per-backend allocation > (bitmap in dir24_8, stack in trie) with a common > refcounted O(1) stack allocator. > - An optional resizable mode (grow via alloc + copy + QSBR > synchronize), removing the need to guess peak usage at > creation time. > - A stats API (rte_fib_tbl8_pool_get_stats()) exposing > used/total/max counters. > > All features are opt-in: > > - Existing per-FIB allocation remains the default. > - Shared pool is enabled via the tbl8_pool config field. > - Resize is enabled by setting max_tbl8 > 0 with QSBR. > > Shrinking (reducing pool capacity after usage drops) is not part of > this series. It would always be best-effort since there is no > compaction: if any tbl8 group near the end of the pool is still in > use, the pool cannot shrink. The current LIFO free-list makes this > less likely by immediately reusing freed high indices, which prevents > a contiguous free tail from forming. A different allocation strategy > (e.g. a min-heap favoring low indices) could improve shrink > opportunities, but is better addressed separately. > > A working integration in Grout is available: > https://github.com/DPDK/grout/pull/581 (still a draft) > > Maxime Leroy (5): > test/fib6: zero-initialize config struct > fib: share tbl8 definitions between fib and fib6 > fib: add shared tbl8 pool > fib: add resizable tbl8 pool > fib: add tbl8 pool stats API > > app/test/test_fib6.c | 10 +- > lib/fib/dir24_8.c | 234 ++++++++++--------------- > lib/fib/dir24_8.h | 17 +- > lib/fib/fib_tbl8.h | 50 ++++++ > lib/fib/fib_tbl8_pool.c | 337 ++++++++++++++++++++++++++++++++++++ > lib/fib/fib_tbl8_pool.h | 113 ++++++++++++ > lib/fib/meson.build | 5 +- > lib/fib/rte_fib.h | 3 + > lib/fib/rte_fib6.h | 3 + > lib/fib/rte_fib_tbl8_pool.h | 149 ++++++++++++++++ > lib/fib/trie.c | 230 +++++++++--------------- > lib/fib/trie.h | 15 +- > 12 files changed, 844 insertions(+), 322 deletions(-) create mode > 100644 lib/fib/fib_tbl8.h create mode 100644 lib/fib/fib_tbl8_pool.c > create mode 100644 lib/fib/fib_tbl8_pool.h create mode 100644 > lib/fib/rte_fib_tbl8_pool.h > I’m following up on this RFC, which I sent at the end of March. Could you please review it and let me know whether you have any feedback or concerns? Thanks, ------------------------------- Maxime Leroy [email protected]
