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!
