From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: Robin Jarry <rjarry@redhat.com>, <dev@dpdk.org>
Subject: Re: rte_fib network order bug
Date: Wed, 13 Nov 2024 10:42:17 +0000 [thread overview]
Message-ID: <da689769-f9e3-43c1-95ce-cd8e0478c4a4@intel.com> (raw)
In-Reply-To: <D5K3GCR2XSBG.287JQOMCHLET6@redhat.com>
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
next prev parent reply other threads:[~2024-11-13 10:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 9:31 Robin Jarry
2024-11-13 10:42 ` Medvedkin, Vladimir [this message]
2024-11-13 13:27 ` Robin Jarry
2024-11-13 19:39 ` Medvedkin, Vladimir
2024-11-14 7:43 ` Morten Brørup
2024-11-14 10:18 ` Robin Jarry
2024-11-14 14:35 ` Morten Brørup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da689769-f9e3-43c1-95ce-cd8e0478c4a4@intel.com \
--to=vladimir.medvedkin@intel.com \
--cc=dev@dpdk.org \
--cc=rjarry@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).