RE: [PATCH dpdk v1 00/15] IPv6 APIs overhaul

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> 
> On Wed, 21 Aug 2024 18:25:17 +0200
> Robin Jarry <rjarry@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.JRQFI6JEH0OX@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.