RE: fib{,6}: questions and proposals

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Robin Jarry [mailto:rjarry@redhat.com]
> Sent: Tuesday, 19 March 2024 21.39
> 
> Hi Vladimir,
> 
> Medvedkin, Vladimir, Mar 19, 2024 at 18:16:

[...]

> > > 4) In rte_fib, every IPv4 address (route *and* next hop) needs to be
> > >    in host order. This is not consistent with fib6 where addresses
> > >    are stored in network order. It took me quite a while to figure
> > >    out what was wrong with my code.
> >
> > This API behavior was created in such a way that it is the same as
> > LPM.
> >
> > As for LPM, I think it was done this way for performance reasons
> > because in some scenarios you only working with the host order ipv4
> > addresses.
> 
> This should really be advertised in strong capital letters in the API
> docs. Or (preferably) hidden to the user. I don't see any valid scenario
> where you would work with host order IPv4 addresses.
> 
> Do you think we could change that API or at least add a flag at FIB/RIB
> creation to make it transparent to the user and consistent between IPv4
> and IPv6?

I agree that it's weird and inconsistent to work with IPv6 addrs in network order, and not do the same for IPv4 addrs.
We should treat IPv4 addrs like IPv6 addrs, instead of dragging around pre-IPv6 legacy host endian IPv4 addresses.
Using a mix of network order and host order for IPv4 addrs is likely to cause bugs.
I would love to see that fixed across all of DPDK, but I suppose API breakage prevents it. :-(