Re: rte_fib network order bug

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 15 Nov 2024 15:28:33 +0100
"Robin Jarry" <rjarry@redhat.com> 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 pain... we're stuck with host endian IPv4 
> > addresses; e.g. for the RTE_IPV4() macro, which I now agree produces 
> > the wrong endian value (on little endian CPUs).  
> 
> At least for 24.11 it is too late. But maybe we could make it right for 
> the next LTS?
> 
> >> Vladimir, could we at least consider adding a real network order mode 
> >> for the rib and fib libraries? So that we can have consistent APIs 
> >> between IPv4 and IPv6?  
> >
> > And/or rename RTE_FIB_F_NETWORK_ORDER to 
> > RTE_FIB_F_NETWORK_ORDER_LOOKUP or similar. This is important if real 
> > network order mode is added (now or later)!  
> 
> Maybe we could revert that patch and defer a complete change of the 
> rib/fib APIs to only expose network order addresses? It would be an ABI 
> breakage but if properly announced in advance, it should be possible.
> 
> Thinking about it some more. Having a flag for such a drastic change in 
> behaviour does not seem right.

It was a mistake for DPDK to define its own data structures for IP addresses.
Would have been much better to stick with the legacy what BSD, Linux (and Windows)
uses in API. 'struct in_addr' and 'struct in6_addr'

Reinvention did not help users.