Re: [PATCH dpdk] fib,rib: implement full network order support for IPv4

["Robin Jarry" <rjarry@redhat.com>]

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/D5SUAHQG4BFP.IRLD8VYLD2U7@redhat.com/

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.