rte_fib network order bug

[Medvedkin, Vladimir]

Hi Robin,

It should not. Here is documentation says regarding this flag:

/** If set, fib lookup is expecting IPv4 address in network byte order */
#define RTE_FIB_F_NETWORK_ORDER    1

As stated above lookups will be performed while expecting addresses to 
be in BE byte order. Control plane API expects IPv4 prefix address to be 
in CPU byte order.

On 12/11/2024 09:31, Robin Jarry wrote:
> Hi Vladimir,
>
> I started playing with the new RTE_FIB_F_NETWORK_ORDER flag and I 
> found that it does not work at all.
>
> rte_fib is based on rte_rib to perform all slow path lookups and 
> modifications. Unfortunately, rte_rib does not handle network order 
> addresses. This causes the added routes to be incorrectly masked and 
> thus inserted at the wrong place in the dir24 structure.
>
> Here is the config I am using:
>
> static struct rte_fib_conf fib_conf = {
>     .type = RTE_FIB_DIR24_8,
>     .default_nh = 0,
>     .max_routes = 65536,
>     .rib_ext_sz = 0,
>     .dir24_8 = {
>         .nh_sz = RTE_FIB_DIR24_8_8B,
>         .num_tbl8 = 1 << 15,
>     },
>     .flags = RTE_FIB_F_NETWORK_ORDER,
> };
>
> And here is a short gdb session demonstrating the issue:
>
> rte_fib_add (fib=0x16ed79740, ip=67305985, depth=24 '\030', 
> next_hop=6438576192) at ../subprojects/dpdk/lib/fib/rte_fib.c:126
> 126             if ((fib == NULL) || (fib->modify == NULL) ||
> (gdb) 129             return fib->modify(fib, ip, depth, next_hop, 
> RTE_FIB_ADD);
> (gdb) p (char*)inet_ntoa(ip)
> $9 = 0x7ffff72a471c "1.2.3.4"
> (gdb) p depth
> $10 = 24 '\030'
> (gdb) p fib->flags $11 = 1 (
> (gdb) s
> dir24_8_modify (fib=0x16ed79740, ip=67305985, depth=24 '\030', 
> next_hop=6438576192, op=0)
>    at ../subprojects/dpdk/lib/fib/dir24_8.c:452
> 452             struct rte_rib_node *tmp = NULL;
> (gdb) n
> 455             int ret = 0;
> (gdb) 458             if ((fib == NULL) || (depth > RTE_FIB_MAXDEPTH))
> (gdb) 461             dp = rte_fib_get_dp(fib);
> (gdb) 462             rib = rte_fib_get_rib(fib);
> (gdb) 465             if (next_hop > get_max_nh(dp->nh_sz))
> (gdb) 468             ip &= rte_rib_depth_to_mask(depth);
> (gdb) p (char*)inet_ntoa(ip)
> $12 = 0x7ffff72a471c "1.2.3.4"
> (gdb) p depth
> $13 = 24 '\030'
> (gdb) n
> 470             node = rte_rib_lookup_exact(rib, ip, depth);
> (gdb) p (char*)inet_ntoa(ip)
> $14 = 0x7ffff72a471c "0.2.3.4"
> (gdb) p (char*)inet_ntoa(rte_rib_depth_to_mask(depth))
> $15 = 0x7ffff72a471c "0.255.255.255"
>
> As you can see, the generated mask is invalid. It should have been 
> 255.255.255.0.
>
> rte_rib would need to have similar network order support and should 
> inherit it from rte_fib.
>
> Let me know if you need more information.
>
-- 
Regards,
Vladimir