From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5D11841C78; Sun, 12 Feb 2023 10:30:12 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C96740E09; Sun, 12 Feb 2023 10:30:12 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 12558400D7 for ; Sun, 12 Feb 2023 10:30:10 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id F20EC41C79; Sun, 12 Feb 2023 10:30:09 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [Bug 1160] IPv4 FIB 0.0.0.0/0 route doesn't work when first route added to FIB and using TBL24_8 Date: Sun, 12 Feb 2023 09:30:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: other X-Bugzilla-Version: 22.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gareth235711@googlemail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=16761942090.6D7a1DF2F.2509485 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --16761942090.6D7a1DF2F.2509485 Date: Sun, 12 Feb 2023 10:30:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1160 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 followi= ng 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 w= orks as expected.=20 void test0(void) { struct rte_fib_conf config =3D { .max_routes =3D 1024, .rib_ext_sz =3D 0, .default_nh =3D 0xDEFA, .type =3D RTE_FIB_DIR24_8, /* test passes for RTE_FIB_DUMMY */ .dir24_8.num_tbl8 =3D 256, .dir24_8.nh_sz =3D RTE_FIB_DIR24_8_4B, }; struct rte_fib* fib =3D 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 =3D rte_fib_add(fib, RTE_IPV4(192,168,0,0), 24, 0x1); //RTE_ASSERT(0 =3D=3D ret); uint64_t next_hop; uint32_t ip =3D RTE_IPV4(10,0,0,1); ret =3D rte_fib_lookup_bulk(fib, &ip, &next_hop, 1); RTE_ASSERT(0 =3D=3D ret); RTE_ASSERT(next_hop =3D=3D 0xDEFA); ret =3D rte_fib_add(fib, RTE_IPV4(0,0,0,0), 0, 0x1); RTE_ASSERT(0 =3D=3D ret); ret =3D rte_fib_lookup_bulk(fib, &ip, &next_hop, 1); RTE_ASSERT(0 =3D=3D ret); printf("nh: 0x%"PRIx64"\n", next_hop); RTE_ASSERT(next_hop =3D=3D 1); /* assertion fail */ } --=20 You are receiving this mail because: You are the assignee for the bug.= --16761942090.6D7a1DF2F.2509485 Date: Sun, 12 Feb 2023 10:30:09 +0100 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
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 w=
orks
as expected.=20



void test0(void) {
    struct rte_fib_conf config =3D {
        .max_routes =3D 1024,
        .rib_ext_sz =3D 0,
        .default_nh =3D 0xDEFA,
        .type =3D RTE_FIB_DIR24_8, /* test passes for RTE_FIB_DUMMY */
        .dir24_8.num_tbl8 =3D 256,
        .dir24_8.nh_sz =3D RTE_FIB_DIR24_8_4B,
    };

    struct rte_fib* fib =3D rte_fib_create("test-fib0", rte_socke=
t_id(),
&config);
    RTE_ASSERT(fib);

    int ret;

    /* works as expected if we add another route before the default route */
    //ret =3D rte_fib_add(fib, RTE_IPV4(192,168,0,0), 24, 0x1);
    //RTE_ASSERT(0 =3D=3D ret);

    uint64_t next_hop;
    uint32_t ip =3D RTE_IPV4(10,0,0,1);
    ret =3D rte_fib_lookup_bulk(fib, &ip, &next_hop, 1);
    RTE_ASSERT(0 =3D=3D ret);
    RTE_ASSERT(next_hop =3D=3D 0xDEFA);

    ret =3D rte_fib_add(fib, RTE_IPV4(0,0,0,0), 0, 0x1);
    RTE_ASSERT(0 =3D=3D ret);

    ret =3D rte_fib_lookup_bulk(fib, &ip, &next_hop, 1);
    RTE_ASSERT(0 =3D=3D ret);
    printf("nh: 0x%"PRIx64"\n", next_hop);
    RTE_ASSERT(next_hop =3D=3D 1); /* assertion fail */
}

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --16761942090.6D7a1DF2F.2509485--