IPv6 APIs rework

[Morten Brørup]

> From: Robin Jarry [mailto:rjarry at redhat.com]
> Sent: Saturday, 20 July 2024 22.33
> 
> Stephen Hemminger, Jul 20, 2024 at 22:26:
> > There is no need for packing or alignment in in6_addr or current DPDK,
> > what would be the benefit?  Compilers generate worse code if
> > a structure is marked packed.
> 
> The only benefit is to maintain current behaviour.
> 
> At first, I had not packed nor aligned anything and I had tons of test
> errors because the compiler added padding in structures that contained
> IPv6 addresses.

If the IPv6 address type you tested with was a struct containing a union of different types (other than an array of 16 bytes), then those sub-types made your IPv6 address type non-byte aligned, and caused padding when used in other structures.

Please try again with the simple array type:
struct rte_ipv6_addr { unsigned char addr_bytes[16]; };

This should not cause any padding when used in other structures, except if used with alignas().

> 
> I don't want to mix things together. In my opinion, removing that
> alignof(1) constraint is an optimization which has nothing to do with
> the IPv6 API functional rework.
> 
> So my proposal is: add a structure *packed and unaligned* first so that
> *all tests are passing*.
> 
> And *then*, after the changes have been applied on the main branch and
> no critical issues have been reported, see if we need to remove these
> packed and unaligned constraints.

If you are introducing an official IPv6 address type into DPDK, its scope it not just the FIB6 API.

Both Stephen and I can see that - in a broader perspective - the packed and unaligned constraints are unacceptable for performance.

It might not be a problem for the current FIB6 implementation, but it *will* be a problem in many other places, if converted to using the new IPv6 address type.

PS:
I do consider adding a dedicated IPv6 address type to DPDK an improvement over the current convention of using an uint8_t[16] array.
But we need to agree on the type, which must work optimally for a broad spectrum of use cases. Otherwise, the new type is not an improvement, but a deterioration of DPDK.