Robin Jarry
Sent: Friday, November 22, 2024 4:15 PM
To: Vladimir Medvedkin ; Stephen Hemminger
Cc: Morten Brørup ; Medvedkin, Vladimir
; dev@dpdk.org; Richardson, Bruce
; Marchand, David ;
Thomas Monjalon ; Konstantin Ananyev
Subject: Re: rte_fib network order bug
Vladimir Medvedkin, Nov 17
Vladimir Medvedkin, Nov 17, 2024 at 16:04:
[Robin]
I had not understood that it was *only* the lookups that were network
order
[Morten]
When I saw the byte order flag the first time, it was not clear to me
either that it only affected lookups - I too thought it covered the
entire API of the
17/11/2024 16:04, Vladimir Medvedkin:
> So, feel free to submit patches adding this feature to the control plane API,
Before discussing more changes, please let's fix the API description in
24.11-rc4:
RTE_FIB_F_NETWORK_ORDER should be renamed RTE_FIB_F_LOOKUP_NETWORK_ORDER
so it matches what it d
Hi all,
[Robin] > I had not understood that it was *only* the lookups that were
network order
[Morten] >When I saw the byte order flag the first time, it was not clear
to me either that it only affected lookups - I too thought it covered the
entire API of the library. This needs to be emphasized i
On Fri, 15 Nov 2024 15:28:33 +0100
"Robin Jarry" wrote:
> Morten Brørup, Nov 15, 2024 at 14:52:
> > Robin, you've totally won me over on this endian discussion. :-)
> > Especially the IPv6 comparison make it clear why IPv4 should also be
> > network byte order.
> >
> > API/ABI stability is a pai
Morten Brørup, Nov 15, 2024 at 14:52:
Robin, you've totally won me over on this endian discussion. :-)
Especially the IPv6 comparison make it clear why IPv4 should also be
network byte order.
API/ABI stability is a pain... we're stuck with host endian IPv4
addresses; e.g. for the RTE_IPV4() m
On Fri, Nov 15, 2024 at 02:52:57PM +0100, Morten Brørup wrote:
> > From: Robin Jarry [mailto:rja...@redhat.com]
> > Sent: Friday, 15 November 2024 14.02
> >
> > Morten Brørup, Nov 14, 2024 at 15:35:
> >
> > On that same topic, I wonder if it would make sense to change the API
> > parameters to
> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Friday, 15 November 2024 14.02
>
> Morten Brørup, Nov 14, 2024 at 15:35:
> >> RTE_IPV4 is only useful to define addresses in unit tests.
> >
> > There are plenty of special IP addresses and subnets, where a
> shortcut
> > macro makes the addre
Morten Brørup, Nov 14, 2024 at 15:35:
RTE_IPV4 is only useful to define addresses in unit tests.
There are plenty of special IP addresses and subnets, where a shortcut
macro makes the address easier readable in the code.
OK, let me reformulate. I didn't mean to say that RTE_IPV4 is useless.
> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Thursday, 14 November 2024 11.19
>
> Hi folks,
>
> Morten Brørup, Nov 14, 2024 at 08:43:
> > Medvedkin, Vladimir:
> >> I think control plane API should work with prefix addresses in CPU
> >> byte order. At least our RTE_IPV4 macro works this
Hi folks,
Morten Brørup, Nov 14, 2024 at 08:43:
Medvedkin, Vladimir:
I think control plane API should work with prefix addresses in CPU
byte order. At least our RTE_IPV4 macro works this way. Also, prefix
is an address + prefix length (not the mask), so it is more natural
if address is in cpu
> -Original Message-
> From: Medvedkin, Vladimir [mailto:vladimir.medved...@intel.com]
> Sent: Wednesday, 13 November 2024 20.39
> To: Robin Jarry; dev@dpdk.org
> Subject: RE: rte_fib network order bug
>
> I think control plane API should work with prefix addresses in
o byteswap on the fast path.
Why do you think this would discourage users?
-Original Message-
From: Robin Jarry
Sent: Wednesday, November 13, 2024 1:27 PM
To: Medvedkin, Vladimir ; dev@dpdk.org
Subject: Re: rte_fib network order bug
Medvedkin, Vladimir, Nov 13, 2024 at 11:42:
> Hi
Medvedkin, Vladimir, Nov 13, 2024 at 11:42:
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 addresse
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
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 b
16 matches
Mail list logo
