Hey Vladimir,
Medvedkin, Vladimir, Nov 03, 2026 at 18:24:
Yes, because the control plane will iterate over the RIB and will
expect addresses to be in a consistent endianness.
Honestly, I would really prefer if that host-order thing was only an
internal implementation detail of the FIB algorithm and that *all*
user facing APIs only dealt with *network order* addresses.
But that would be a hard-break of the ABI. Would that be so terrible?
Who reasonably needs IPv4 host-order addresses for real world
applications?
I think we can't just give up host order, we need to maintain some
level of backward compatibility with the good old LPM library. People
have been using it for a long time and have built their code around
its API, which uses host order in both the control and data planes.
Too bad, it was worth a try ;)
I would be interested to know which real applications use the LPM/FIB
libraries. It would give us some confidence if we ever need to break the
APIs.
FIB keeps the same semantics, which makes migrating from LPM
straightforward. The problem with a hard break is not only the ABI,
function prototypes remains the same (use uint32_t), so existing apps
would still compile and links without warnings, they just will install
byte-swapped routes.
Yeah, we had talked about this last year [1]. The solutions wouldn't be
pretty. We would need to change the APIs to use a struct instead of
integers. That wouldn't be that bad honestly.
[1] https://inbox.dpdk.org/dev/[email protected]/
Let's table this discussion for next time.
The existing RTE_FIB_F_LOOKUP_NETWORK_ORDER flag has been there since
24.11 and is part of two LTS releases, so I would keep it as is, at
least for a while.
However you have a fair point about the RIB, it is exposed through
rte_fib_get_rib(), it is not 100% internal, and user may expect to
have the same byte order as was used for FIB add/del. I'm fine with
propagating the flag to the internal RIB, although we can just mark
host order in documentation.
So I'd suggest:
- keep host order (for both CP and DP ops) as default (to maintain
alignment with legacy LPM)
- keep RTE_FIB_F_LOOKUP_NETWORK_ORDER unchanged (lookup only)
- add a new flag that makes all IPv4 operations (CP and DP) use
network order (with this flag order propagated to the RIB if you
think it would be better)
OK.
--
Robin
# Portions not affecting outcome have been edited for broadcast.
