Morten Brørup, Aug 22, 2024 at 17:13:
The types seem to be different in the Windows API (than in Linux/BSD):
https://github.com/tpn/winsdk-10/blob/9b69fd26ac0c7d0b83d378dba01080e93349c2ed/Include/10.0.14393.0/shared/in6addr.h#L25
https://github.com/tpn/winsdk-10/blob/9b69fd26ac0c7d0b83d378dba01080e93349c2ed/Include/10.0.16299.0/shared/inaddr.h#L25
Furthermore, but less important:
The existing in the Linux/BSD/Windows IPv6 address type are 2-byte aligned.
At least BSD is 4 bytes aligned.
https://github.com/freebsd/freebsd-src/blob/498286d4e807d6b9e4caad22b96ebca7f16e9b18/sys/netinet6/in6.h#L91-L100
And on Linux, it depends on the libc implementation?
https://github.com/torvalds/linux/blob/872cf28b8df9c5c3a1e71a88ee750df7c2513971/include/uapi/linux/in6.h#L33
In the RFC discussion, we agreed to omit any alignment requirements for the
DPDK IPv6 address, for tunneling purposes.
We could introduce 2-byte alignment later, using a union and an array of
uint16_t, if beneficial.
Which makes me think...
Maybe the 'a' field in the DPDK IPv6 address structure should be named 'b' for "byte"
instead, to prepare it for adding a union with a 'w' (for "word") field if we want to
introduce 2-byte alignment.
My idea was to name the field a16 instead of w which would be confusing.
Also, how would you name a 32 bit array field if it presented itself?
