https://bugs.dpdk.org/show_bug.cgi?id=1160 Bug ID: 1160 Summary: IPv4 FIB 0.0.0.0/0 route doesn't work when first route added to FIB and using TBL24_8 Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: gareth235711@googlemail.com Target Milestone: --- I think there's an issue with rte_fib which occurs when both of the following conditions are met: 1. A route of 0.0.0.0/0 is the first route added to the FIB 2. The FIB is configured with type RTE_FIB_DIR24_8 Under these conditions, rte_fib_add returns with no error but subsequent lookups that should hit the 0.0.0.0/0 route (and miss all others) return the default next hop from the FIB config, not the next hop specified when adding the 0.0.0.0/0. If another route with a longer prefix is added first, the 0.0.0.0/0 route works as expected. void test0(void) { struct rte_fib_conf config = { .max_routes = 1024, .rib_ext_sz = 0, .default_nh = 0xDEFA, .type = RTE_FIB_DIR24_8, /* test passes for RTE_FIB_DUMMY */ .dir24_8.num_tbl8 = 256, .dir24_8.nh_sz = RTE_FIB_DIR24_8_4B, }; struct rte_fib* fib = rte_fib_create("test-fib0", rte_socket_id(), &config); RTE_ASSERT(fib); int ret; /* works as expected if we add another route before the default route */ //ret = rte_fib_add(fib, RTE_IPV4(192,168,0,0), 24, 0x1); //RTE_ASSERT(0 == ret); uint64_t next_hop; uint32_t ip = RTE_IPV4(10,0,0,1); ret = rte_fib_lookup_bulk(fib, &ip, &next_hop, 1); RTE_ASSERT(0 == ret); RTE_ASSERT(next_hop == 0xDEFA); ret = rte_fib_add(fib, RTE_IPV4(0,0,0,0), 0, 0x1); RTE_ASSERT(0 == ret); ret = rte_fib_lookup_bulk(fib, &ip, &next_hop, 1); RTE_ASSERT(0 == ret); printf("nh: 0x%"PRIx64"\n", next_hop); RTE_ASSERT(next_hop == 1); /* assertion fail */ } -- You are receiving this mail because: You are the assignee for the bug.