rte_fib network order bug

[Robin Jarry]

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. 
But it will always generate addresses in *host order*. Which means they 
cannot be used in IPv4 headers without passing them through htonl().
This is weird in my opinion.

>> Why would control plane use a different representation of addresses
>> compared to data plane?
>
> Excellent question.
> Old habit? Growing up using big endian CPUs, we have come to think of 
> IPv4 addresses as 32 bit numbers, so we keep treating them as such. 
> With this old way of thinking, the only reason to use network endian 
> in the fast path with little endian CPUs is for performance reasons 
> (to save the byte swap) - if not, we would still prefer using host 
> endian in the fast path too.

I understand the implementation reasons why you would prefer working 
with host order integers. But the APIs that deal with IPv4 addresses 
should not reflect implementation details.

>> Also for consistency with IPv6, I really think
>> that *all* addresses should be dealt in their network form.
>
> Food for thought!

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?

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.

Thanks!