Re: [PATCH net-next] net: ipv4: add lwtunnel hash to fib_info_hash to fix mpls collisions

[Ido Schimmel <idosch@nvidia.com>]

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 <guschin108@gmail.com>
> ---
> 
> 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