From: Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
To: Robin Jarry <rjarry@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>,
Jerin Jacob <jerinj@marvell.com>,
Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
Zhirun Yan <yanzhirun_163@163.com>
Subject: RE: [EXTERNAL] [PATCH v6] graph: expose node context as pointers
Date: Fri, 12 Jul 2024 11:39:49 +0000 [thread overview]
Message-ID: <PH0PR18MB5071B4F4332259E6FF052347ACA62@PH0PR18MB5071.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20240705145254.558221-3-rjarry@redhat.com>
> -----Original Message-----
> From: Robin Jarry <rjarry@redhat.com>
> Sent: Friday, July 5, 2024 8:23 PM
> To: dev@dpdk.org; Jerin Jacob <jerinj@marvell.com>; Kiran Kumar
> Kokkilagadda <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Zhirun Yan <yanzhirun_163@163.com>
> Subject: [EXTERNAL] [PATCH v6] graph: expose node context as pointers
>
> 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
> 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 itself cache aligned. Use __rte_cache_aligned to
> preserve existing alignment on architectures where cache lines are 128 bytes.
>
> Add a static assert to ensure that the fast path area does not grow beyond a
> 64 bytes cache line.
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> ---
Acked-by: Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
>
> Notes:
> v6:
>
> * Fix ABI breakage on arm64 (and all platforms that have
> RTE_CACHE_LINE_SIZE=128).
> * This patch will cause CI failures without libabigail 2.5. See this commit
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__sourceware.org_git_-3Fp-3Dlibabigail.git-3Ba-3Dcommitdiff-3Bh-
> 3Df821c2be3fff2047ef8fc436f6f02301812d166f&d=DwIDAg&c=nKjWec2b6R0m
> OyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=p2InA
> hlxVf3SXbWbwMoGbsA2ylexBEm_WKDY6mf88Lgp6hbAD5UNuKGkFiO0F8vV&
> s=mtRUGLkylM_33OiTJTBoxFQNDQh6p7xIyNwmDu9GgTk&e=
> for more details.
>
> 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.
>
> v4:
>
> * Replaced the unnamed union with helper inline functions.
>
> v3:
>
> * Added __extension__ to the unnamed struct inside the union.
> * Fixed C++ header checks.
> * Replaced alignas() with an explicit static_assert.
>
> lib/graph/rte_graph_worker_common.h | 29 +++++++++++++++++++++--------
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index 36d864e2c14e..8d8956fdddda 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -12,7 +12,9 @@
> * process, enqueue and move streams of objects to the next nodes.
> */
>
> +#include <assert.h>
> #include <stdalign.h>
> +#include <stddef.h>
>
> #include <rte_common.h>
> #include <rte_cycles.h>
> @@ -111,14 +113,21 @@ struct __rte_cache_aligned rte_node {
> } dispatch;
> };
> /* Fast path area */
> + __extension__ struct __rte_cache_aligned {
> #define RTE_NODE_CTX_SZ 16
> - alignas(RTE_CACHE_LINE_SIZE) uint8_t ctx[RTE_NODE_CTX_SZ]; /**<
> Node Context. */
> - uint16_t size; /**< Total number of objects available. */
> - uint16_t idx; /**< Number of objects used. */
> - rte_graph_off_t off; /**< Offset of node in the graph reel. */
> - uint64_t total_cycles; /**< Cycles spent in this node. */
> - uint64_t total_calls; /**< Calls done to this node. */
> - uint64_t total_objs; /**< Objects processed by this node. */
> + union {
> + uint8_t ctx[RTE_NODE_CTX_SZ];
> + __extension__ struct {
> + void *ctx_ptr;
> + void *ctx_ptr2;
> + };
> + }; /**< Node Context. */
> + uint16_t size; /**< Total number of objects
> available. */
> + uint16_t idx; /**< Number of objects used. */
> + rte_graph_off_t off; /**< Offset of node in the graph reel.
> */
> + uint64_t total_cycles; /**< Cycles spent in this node. */
> + uint64_t total_calls; /**< Calls done to this node. */
> + uint64_t total_objs; /**< Objects processed by this node.
> */
> union {
> void **objs; /**< Array of object pointers. */
> uint64_t objs_u64;
> @@ -127,9 +136,13 @@ struct __rte_cache_aligned rte_node {
> rte_node_process_t process; /**< Process function.
> */
> uint64_t process_u64;
> };
> - alignas(RTE_CACHE_LINE_MIN_SIZE) struct rte_node *nodes[]; /**<
> Next nodes. */
> + alignas(RTE_CACHE_LINE_MIN_SIZE) struct rte_node
> *nodes[]; /**< Next nodes. */
> + };
> };
>
> +static_assert(offsetof(struct rte_node, nodes) - offsetof(struct rte_node, ctx)
> + == RTE_CACHE_LINE_MIN_SIZE, "rte_node fast path area must fit in
> 64
> +bytes");
> +
> /**
> * @internal
> *
> --
> 2.45.2
prev parent reply other threads:[~2024-07-12 11:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 14:52 Robin Jarry
2024-07-12 11:39 ` Kiran Kumar Kokkilagadda [this message]
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=PH0PR18MB5071B4F4332259E6FF052347ACA62@PH0PR18MB5071.namprd18.prod.outlook.com \
--to=kirankumark@marvell.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=ndabilpuram@marvell.com \
--cc=rjarry@redhat.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).