On Sun, Feb 22, 2026 at 01:05:39AM +0000, Vitaliy Guschin wrote:

Currently, fib_info_hash_bucket does not account for MPLS labels
(lwtunnel state) when calculating the hash for fib_info objects. This leads
to massive hash collisions when many routes are configured with the same
gateway but different MPLS labels.

To resolve this, introduce lwtunnel_get_encap_hash() helper which calls a
new .get_encap_hash callback in lwtunnel_encap_ops. Implement this callback
for mpls_iptunnel to provide a hash of the MPLS label set.

This ensures proper distribution in the fib_info_hash table, improving
route installation and deletion performance by avoiding massive hash
collisions. In a test case with 100,000 MPLS routes, this changes the
algorithmic complexity from O(N) lookup in a single bucket to a
well-distributed hash table lookup.

Performance test (Batch installation of 100,000 routes with MPLS labels):
CPU: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz

- Before patch: 6m 0.258s (sys 5m 56.895s)
- After patch:  0m 0.879s (sys 0m 0.468s)

Signed-off-by: Vitaliy Guschin <redacted>
---

Hi all,

This patch addresses a major performance bottleneck in the fib_info_hash
table when using MPLS encapsulation. Currently, the hash calculation
for fib_info objects ignores lwtunnel state, leading to O(N) collisions
when many routes share the same gateway but use different MPLS labels

This specifically affects route installation and deletion performance,
as all fib_info objects end up in the same hash bucket.

The test script:

#!/bin/bash

for i in {1..100000}; do 
    echo "route add 100.$((i>>16&255)).$((i>>8&255)).$((i&255))/32 encap mpls \
    $((i+15)) via inet 192.168.1.1 dev eth0"
done > batch.txt

time ip -batch batch.txt

Test results:

Before patch

real    6m0.258s
user    0m0.335s
sys     5m56.895s

After patch

real    0m0.879s
user    0m0.397s
sys     0m0.468s

Did you consider using the nexthop API [1]?

It doesn't suffer from this problem since the nexthop ID is used in the
FIB info hash computation and it does not require patching every LWT
family.

[1]
# cat lwt_hash_nhid.sh 
#!/bin/bash

ip link add name dummy1 up type dummy
ip address add 192.168.1.2/24 dev dummy1

rm -f /tmp/batch.txt
for i in {1..100000}; do
        echo "nexthop add id $i encap mpls $((i+15)) via 192.168.1.1 dev dummy1"
        echo "route add 100.$((i>>16&255)).$((i>>8&255)).$((i&255))/32 nhid $i"
done > /tmp/batch.txt

time ip -batch /tmp/batch.txt
# ./lwt_hash_nhid.sh 

real    0m0.467s
user    0m0.109s
sys     0m0.347s