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
