>>> 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.
>>
>> Do I understand it right that the idea here would be to flip the
>> endianness right before pulling stable/2009 branch ?
>
> If this is done right before (or near) the branch pull for 2009 then I think
> the release candidate should be left to bake longer than normal, and API
> users encouraged to port/test to the release candidate. Obviously any bugs
> found would then be fixed on the RC. Maybe ask for a couple/few stakeholders
> to sign up to do this and then wait a reasonable amount of time for them to
> sign-off?
>
> I know we use the binary APIs, I believe Netgate does as well. I'm sure there
> are others too (might be good to collect a list of these folks if one doesn't
> exist yet).
>
> If these changes were coupled with the (more important IMO) change i've been
> (ceaselessly :) asking for in the API (non-callback sync functions) I would
> be more than willing to sign up for this.
I am a little concerned about the benefits of switching the endian
representation in the wire format.
The endianness and representation on the wire should not be exposed to the
client-side or VPP API handler code.
The language bindings I am familiar with hide endian issues from the user code.
Python and Go. I think VAPI does too.
VPP API action handlers do currently need to deal with endianness. That should
be a relatively simple change.
I can add a new flag in the message definition in the API, and then wrap those
action handlers with endian functions. Then we can avoid having VPP developers
manually do endian conversions for API functions.
The current on-the-wire representation is that of packed C structures, and we
are somewhat a victim of that. E.g. how the compiler puts various members of a
union in memory is as far as I know not part of the C standard.
I would suggests we move towards isolating user-side and VPP-side code from
endianess and encoding (and we can do that evolutionary) and then consider if
we can move towards a better specified encoding format. If that's CBOR,
Flatbuffers or something else.
Christian for your VAPI C callback issue, that I believe is purely under the
control of the language binding.
Can I volunteer you ti fix that?
Best regards,
Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16435): https://lists.fd.io/g/vpp-dev/message/16435
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]
-=-=-=-=-=-=-=-=-=-=-=-
