> From: Robin Jarry [mailto:rja...@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.
