[PATCH v3 12/18] malloc: fix mp message alignment

[David Marchand]

On Tue, Jul 8, 2025 at 3:26 PM Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> On Tue, Jul 08, 2025 at 02:46:04PM +0200, David Marchand wrote:
> > On Tue, Jul 8, 2025 at 2:44 PM Bruce Richardson
> > <bruce.richardson at intel.com> wrote:
> > >
> > > On Tue, Jul 08, 2025 at 02:28:16PM +0200, David Marchand wrote:
> > > > Content (param[]) of received multiprocess messages are aligned with
> > > > a 4 bytes constraint.
> > > >
> > > > Before patch:
> > > > struct mp_msg_internal {
> > > >  int type;                                                     /*   0     4 */
> > > >  struct rte_mp_msg {
> > > >   char name[64];                                               /*   4    64 */
> > > >   /* --- cacheline 1 boundary (64 bytes) was 4 bytes ago --- */
> > > >   int len_param;                                               /*  68     4 */
> > > >   int num_fds;                                                 /*  72     4 */
> > > >   /* typedef uint8_t -> __uint8_t */ unsigned char param[256]; /*  76   256 */
> > > >   /* --- cacheline 5 boundary (320 bytes) was 12 bytes ago --- */
> > > >   int fds[253];                                                /* 332  1012 */
> > > >  } msg;                                                        /*   4  1340 */
> > > >
> > > >  /* size: 1344, cachelines: 21, members: 2 */
> > > > };
> > > >
> > > > This results in many unaligned accesses for multiprocess malloc requests.
> > > >
> > > > Examples:
> > > > ../lib/eal/common/malloc_mp.c:308:32: runtime error:
> > > >       member access within misaligned address 0x7f7b35df4684 for type
> > > >       'const struct malloc_mp_req', which requires 8 byte alignment
> > > >
> > > > ../lib/eal/common/malloc_mp.c:158:9: runtime error:
> > > >       member access within misaligned address 0x7f36a535bb5c for type
> > > >       'const struct malloc_mp_req', which requires 8 byte alignment
> > > >
> > > > ../lib/eal/common/malloc_mp.c:171:8: runtime error:
> > > >       member access within misaligned address 0x7f4ba65f296c for type
> > > >       'struct malloc_mp_req', which requires 8 byte alignment
> > > >
> > > > Signed-off-by: David Marchand <david.marchand at redhat.com>
> > > > ---
> > > >  lib/eal/common/eal_common_proc.c |  2 +-
> > > >  lib/eal/common/malloc_mp.c       | 18 +++++++++---------
> > > >  2 files changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/lib/eal/common/eal_common_proc.c b/lib/eal/common/eal_common_proc.c
> > > > index 0dea787e38..3846c7178d 100644
> > > > --- a/lib/eal/common/eal_common_proc.c
> > > > +++ b/lib/eal/common/eal_common_proc.c
> > > > @@ -62,7 +62,7 @@ enum mp_type {
> > > >
> > > >  struct mp_msg_internal {
> > > >       int type;
> > > > -     struct rte_mp_msg msg;
> > > > +     alignas(8) struct rte_mp_msg msg;
> > > >  };
> > > >
> > > >  struct async_request_param {
> > > > diff --git a/lib/eal/common/malloc_mp.c b/lib/eal/common/malloc_mp.c
> > > > index 9765277f5d..000c7f6b47 100644
> > > > --- a/lib/eal/common/malloc_mp.c
> > > > +++ b/lib/eal/common/malloc_mp.c
> > > > @@ -148,7 +148,7 @@ get_unique_id(void)
> > > >  static int
> > > >  handle_sync(const struct rte_mp_msg *msg, const void *peer)
> > > >  {
> > > > -     struct rte_mp_msg reply;
> > > > +     alignas(8) struct rte_mp_msg reply;
> > > >       const struct malloc_mp_req *req =
> > > >                       (const struct malloc_mp_req *)msg->param;
> > >
> > > This patch seems to have a lot of these definitions with alignas added to
> > > them. Would it be simpler just to put the alignas inside the rte_mp_msg
> > > definition?
> > >
> > > More specifically, if its the "uint8_t param" element that needs alignment,
> > > how about changing that specific field to make it aligned?
> >
> > We could probably enhance this, but I expect this breaks ABI.
> >
> Is the multi-process message type part of the public ABI? I don't believe
> we ever guaranteed multiprocess support working across versions of DPDK.

An application can register its own callbacks which take a rte_mp_msg as input.
Hum... would it really be an ABI breakage though... need to think.

At least I tested, and the ABI check is complaining.


-- 
David Marchand