DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: Robin Jarry <rjarry@redhat.com>
Cc: dev@dpdk.org, Jerin Jacob <jerinj@marvell.com>,
	 Kiran Kumar K <kirankumark@marvell.com>,
	Nithin Dabilpuram <ndabilpuram@marvell.com>,
	 Zhirun Yan <yanzhirun_163@163.com>,
	Tyler Retzlaff <roretzla@linux.microsoft.com>
Subject: Re: [PATCH v5] graph: expose node context as pointers
Date: Tue, 18 Jun 2024 14:33:05 +0200	[thread overview]
Message-ID: <CAJFAV8y6y+TsDtR52z3=EQnEOcn87RX+E0KqiW2Fi-hwnGDYSg@mail.gmail.com> (raw)
In-Reply-To: <20240327091440.1166119-2-rjarry@redhat.com>

Re Robin,

On Wed, Mar 27, 2024 at 10:17 AM Robin Jarry <rjarry@redhat.com> wrote:
>
> In some cases, the node context data is used to store two pointers
> because the data is larger than the reserved 16 bytes. Having to define
> intermediate structures just to be able to cast is tedious. And without
> intermediate structures, casting to opaque pointers is hard without
> violating strict aliasing rules.
>
> Add an unnamed union to allow storing opaque pointers in the node
> context. Unfortunately, aligning an unnamed union that contains an array
> produces inconsistent results between C and C++. To preserve ABI/API
> compatibility in both C and C++, move all fast-path area fields into an
> unnamed struct which is cache aligned. Use __rte_cache_min_aligned to
> preserve existing alignment on architectures where cache lines are 128
> bytes.
>
> Add a static assert to ensure that the unnamed union is not larger than
> the context array (RTE_NODE_CTX_SZ).
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> ---
>
> Notes:
>     v5:
>
>     * Helper functions to hide casting proved to be harder than expected.
>       Naive casting may even be impossible without breaking strict aliasing
>       rules. The only other option would be to use explicit memcpy calls.
>     * Unnamed union tentative again. As suggested by Tyler (thank you!),
>       using an intermediate unnamed struct to carry the alignment produces
>       consistent ABI in C and C++.
>     * Also, Tyler (thank you!) suggested that the fast path area alignment
>       size may be incorrect for architectures where the cache line is not 64
>       bytes. There will be a 64 bytes hole in the structure at the end of
>       the unnamed struct before the zero length next nodes array. Use
>       __rte_cache_min_aligned to preserve existing alignment.

- There is still an issue with that approach on 128 bytes cache line
arches, like ARM.
This results in a ABI breakage:

Functions changes summary: 0 Removed, 1 Changed (9 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

1 function with some indirect sub-type change:

  [C] 'function bool
__rte_graph_mcore_dispatch_sched_node_enqueue(rte_node*,
rte_graph_rq_head*)' at rte_graph_model_mcore_dispatch.c:117:1 has
some indirect sub-type changes:
    parameter 1 of type 'rte_node*' has sub-type changes:
      in pointed to type 'struct rte_node' at rte_graph_worker_common.h:92:1:
        type size changed from 3072 to 2048 (in bits)
        7 data member deletions:
          'uint8_t ctx[16]', at offset 2048 (in bits) at
rte_graph_worker_common.h:115:1
          'uint16_t size', at offset 2176 (in bits) at
rte_graph_worker_common.h:116:1
          'uint16_t idx', at offset 2192 (in bits) at
rte_graph_worker_common.h:117:1
          'rte_graph_off_t off', at offset 2208 (in bits) at
rte_graph_worker_common.h:118:1
          'uint64_t total_cycles', at offset 2240 (in bits) at
rte_graph_worker_common.h:119:1
          'uint64_t total_calls', at offset 2304 (in bits) at
rte_graph_worker_common.h:120:1
          'uint64_t total_objs', at offset 2368 (in bits) at
rte_graph_worker_common.h:121:1
        1 data member insertion:
          'struct {union {uint8_t ctx[16]; struct {void* ctx_ptr;
void* ctx_ptr2;};}; uint16_t size; uint16_t idx; rte_graph_off_t off;
uint64_t total_cycles; uint64_t total_calls; uint64_t total_objs;
union {void** objs; uint64_t objs_u64;}; union {rte_node_process_t
process; uint64_t process_u64;};}', at offset 1536 (in bits)
        1 data member changes (1 filtered):
          'rte_node* nodes[]' offset changed from 2560 to 2048 (in
bits) (by -512 bits)


Before the patch, the rte_node object layout was:

struct rte_node {
...
        /* XXX 64 bytes hole, try to pack */

        /* --- cacheline 4 boundary (256 bytes) --- */
        uint8_t                    ctx[16]
__attribute__((__aligned__(128))); /*   256    16 */
        uint16_t                   size;                 /*   272     2 */
        uint16_t                   idx;                  /*   274     2 */
        rte_graph_off_t            off;                  /*   276     4 */
        uint64_t                   total_cycles;         /*   280     8 */
        uint64_t                   total_calls;          /*   288     8 */
        uint64_t                   total_objs;           /*   296     8 */
        union {
                void * *           objs;                 /*   304     8 */
                uint64_t           objs_u64;             /*   304     8 */
        };                                               /*   304     8 */
        union {
                rte_node_process_t process;              /*   312     8 */
                uint64_t           process_u64;          /*   312     8 */
        };                                               /*   312     8 */
        /* --- cacheline 5 boundary (320 bytes) --- */
        struct rte_node *          nodes[]
__attribute__((__aligned__(64))); /*   320     0 */

        /* size: 384, cachelines: 6, members: 20 */
        /* sum members: 250, holes: 3, sum holes: 70 */
        /* padding: 64 */
        /* forced alignments: 2, forced holes: 1, sum forced holes: 64 */
} __attribute__((__aligned__(128)));


After this patch:

struct rte_node {
...
        /* --- cacheline 3 boundary (192 bytes) --- */
        struct {
                union {
                        uint8_t    ctx[16];              /*   192    16 */
                        struct {
                                void * ctx_ptr;          /*   192     8 */
                                void * ctx_ptr2;         /*   200     8 */
                        };                               /*   192    16 */
                };                                       /*   192    16 */
                uint16_t           size;                 /*   208     2 */
                uint16_t           idx;                  /*   210     2 */
                rte_graph_off_t    off;                  /*   212     4 */
                uint64_t           total_cycles;         /*   216     8 */
                uint64_t           total_calls;          /*   224     8 */
                uint64_t           total_objs;           /*   232     8 */
                union {
                        void * *   objs;                 /*   240     8 */
                        uint64_t   objs_u64;             /*   240     8 */
                };                                       /*   240     8 */
                union {
                        rte_node_process_t process;      /*   248     8 */
                        uint64_t   process_u64;          /*   248     8 */
                };                                       /*   248     8 */
        } __attribute__((__aligned__(64)))
__attribute__((__aligned__(64)));              /*   192    64 */
        /* --- cacheline 4 boundary (256 bytes) --- */
        struct rte_node *          nodes[]
__attribute__((__aligned__(64))); /*   256     0 */

        /* size: 256, cachelines: 4, members: 12 */
        /* sum members: 250, holes: 2, sum holes: 6 */
        /* forced alignments: 2 */
} __attribute__((__aligned__(128)));

The introduced anonymous structure gets aligned on the minimum cache
line size (64 bytes): with this change, ctx[] move from offset 256, to
offset 192.
Similarly, nodes[] moves from offset 320 to offset 256.

As we discussed offlist, there are a few options to workaround this
issue (like moving nodes[] inside the anonymous struct though it still
results in an increased rte_node struct, or like adding an explicit
padding field right before the newly introduced anonymous struct,
...).


- Additionally, anonymous structures are not correctly handled with
libabigail 2.4 which is the version used in the CI.
At the moment, the ABI check in GHA and UNH will fail on x86 with:

1 function with some indirect sub-type change:

  [C] 'function bool
__rte_graph_mcore_dispatch_sched_node_enqueue(rte_node*,
rte_graph_rq_head*)' at rte_graph_model_mcore_dispatch.c:117:1 has
some indirect sub-type changes:
    parameter 1 of type 'rte_node*' has sub-type changes:
      in pointed to type 'struct rte_node' at rte_graph_worker_common.h:92:1:
        type size hasn't changed
        2 data member deletions:
          'union {void** objs; uint64_t objs_u64;}', at offset 1920 (in bits)
          'union {rte_node_process_t process; uint64_t process_u64;}',
at offset 1984 (in bits)
        no data member changes (2 filtered);

On this topic, we have to either put a suppression rule on the
rte_node structure, or bump the libabigail version in UNH, GHA, and
the maintainers build env (though the latter won't happen overnight,
and we are really close to rc1).



For those two reasons, it is better to revisit this patch and have it
ready for the next release.
While at it, it may be worth cleaning up the rte_node structure in
v24.11, if so, please announce in a deprecation notice for this
planned ABI breakage.


-- 
David Marchand


  parent reply	other threads:[~2024-06-18 12:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25 10:05 [PATCH v3] " Robin Jarry
2024-03-25 10:59 ` Jerin Jacob
2024-03-25 11:02   ` Robin Jarry
2024-03-25 11:08     ` Jerin Jacob
2024-03-25 11:15       ` Robin Jarry
2024-03-25 11:35         ` Jerin Jacob
2024-03-25 12:07           ` Bruce Richardson
2024-03-25 12:08           ` David Marchand
2024-03-25 15:20           ` Robin Jarry
2024-03-25 15:47             ` Jerin Jacob
2024-03-25 15:51               ` Robin Jarry
2024-03-25 15:56                 ` Jerin Jacob
2024-03-25 16:31 ` [PATCH v4] " Robin Jarry
2024-03-25 16:50   ` Jerin Jacob
2024-03-27  9:14 ` [PATCH v5] " Robin Jarry
2024-05-29 17:54   ` Nithin Dabilpuram
2024-06-18 12:33   ` David Marchand [this message]
2024-06-25 15:22     ` Robin Jarry
2024-06-26 11:30       ` Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJFAV8y6y+TsDtR52z3=EQnEOcn87RX+E0KqiW2Fi-hwnGDYSg@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=kirankumark@marvell.com \
    --cc=ndabilpuram@marvell.com \
    --cc=rjarry@redhat.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=yanzhirun_163@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).