Medvedkin, Vladimir, Nov 13, 2024 at 11:42:
Hi Robin,
It should not. Here is documentation says regarding this flag:
/** If set, fib lookup is expecting IPv4 address in network byte order */
#define RTE_FIB_F_NETWORK_ORDER 1
As stated above lookups will be performed while expecting addresses to
be in BE byte order. Control plane API expects IPv4 prefix address to be
in CPU byte order.
I had not understood that it was *only* the lookups that were network
order.
The original reason why a RTE_FIB_F_NETWORK_ORDER flag was suggested
some time ago is that inet_pton() always returns network order
addresses. It makes it much more natural to keep everything in network
order instead of having to swap things around.
Now, only having the lookup functions requiring network order addresses
but all the other functions in the API requiring host order addresses is
even more confusing.
In my opinion, when RTE_FIB_F_NETWORK_ORDER is set, *all* functions of
the fib API should take network order addresses. That obviously mean
that rib should also have a similar flag.
Is that possible without a massive rework? If not, then I think we
should revert the patch that adds it or at least discourage its use in
its current state.
What do you think?
