> API messages in network byte order made sense 10 years ago when I worked with > a mixed x86_64 / ppc32 system. As Damjan points out, API interoperability > between big-endian and little-endian systems is a boutique use-case these > days. > > Timing is key. We won’t be able to cherry-pick API message handler fixes > across an endian-order flag-day. If we decide to switch to native byte order, > we’d better switch right before we pull our next LTS release.
Here is a draft patch that moves endian conversion into the API infrastructure: https://gerrit.fd.io/r/c/vpp/+/27119 If we first move all the API handlers to native endian, and leave it to the API infrastructure to do endian conversion, we can even allow for clients to negotiate what endianness they want. That move we can do without affecting the API clients as the on-the-wire encoding will be the same. Regarding that patch; I might want to hide the endian conversion inside of vl_api_send_msg() instead of in the REPLY macro(s). There are some mess to tidy up, like client_index is used native endian for shared memory clients, but not for socket clients. Cheers, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16438): https://lists.fd.io/g/vpp-dev/message/16438 Mute This Topic: https://lists.fd.io/mt/74228149/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
