> From: Stephen Hemminger [mailto:step...@networkplumber.org] > > On Wed, 21 Aug 2024 18:25:17 +0200 > Robin Jarry <rja...@redhat.com> wrote: > > > Hi everyone, > > > > As discussed recently [1], here is a first draft of the IPv6 APIs rework. > The > > API change was announced before the 24.07 release [2]. This series is > intended > > for 24.11. > > > > [1] http://inbox.dpdk.org/dev/d2sr8t1h39cj.jrqfi6jeh...@redhat.com/ > > [2] > https://git.dpdk.org/dpdk/commit/?id=835d4c41e0ab58a115c2170c886ba6d3cc1b5764 > > > > I tried to keep the patches as small as possible; unfortunately some of them > > are quite big and cannot be broken down if we want to preserve a bisectable > > tree. > > > > Let me know what you think. > > Let me ask a couple of questions about this. > > Why does DPDK need to have its own definitions of IPv4 and IPv6 addresses? > The structures in_addr and in6_addr exist on Linux, BSD, and Windows. > It creates lots of code reimplementation (see inet_ntop etc). > > > What advantage is there to having our own definitions?
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. 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.
