rte_fib network order bug

[Bruce Richardson]

On Fri, Nov 15, 2024 at 02:52:57PM +0100, Morten Brørup wrote:
> > From: Robin Jarry [mailto:rjarry at redhat.com]
> > Sent: Friday, 15 November 2024 14.02
> > 
> > Morten Brørup, Nov 14, 2024 at 15:35:
<snip> 
> > 
> > On that same topic, I wonder if it would make sense to change the API
> > parameters to use an opaque rte_ipv4_addr_t type instead of a native
> > uint32_t to avoid any confusion.
> 
> It could be considered an IPv4 address type (like the IPv6 address type) (which should be in network endian), which it is not, so I don't like this idea.

Can you clarify your objection to this idea? For me, the idea of having
IPv4 addresses as a 4-byte array seems to offer a lot of advantages over
treating it as a single 32-bit value. We don't need to worry about packing
or alignment of the values, and everything would always be treated in network-byte
order. The main downside I see is compatibility - we'd need a whole new set
of definitions and functions in libs to make the change.

/Bruce