From: "Morten Brørup" <mb@smartsharesystems.com>
To: <scott.k.mitch1@gmail.com>, <dev@dpdk.org>
Cc: <stephen@networkplumber.org>, <bruce.richardson@intel.com>
Subject: RE: [PATCH v17 2/2] eal: RTE_PTR_ADD/SUB API improvements
Date: Tue, 3 Feb 2026 10:08:33 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F656E6@smartserver.smartshare.dk> (raw)
In-Reply-To: <20260202052442.92192-3-scott.k.mitch1@gmail.com>
> RTE_PTR_ADD and RTE_PTR_SUB APIs have a few limitations:
> 1. ptr cast to uintptr_t drops pointer provenance and
> prevents compiler optimizations
> 2. return cast discards qualifiers (const, volatile)
> which may hide correctness/concurrency issues.
> 3. Accepts both "pointers" and "integers as pointers" which
> overloads the use case and constrains the implementation
> to address other challenges.
>
> This patch splits the API on two dimensions:
> 1. pointer types
Again, thank you for all the work you put into this, Scott!
> 2. integer types that represent pointers
Please get rid of all the RTE_INT_PTR macros.
IMO, these macros look too much like plain wrappers around simple +/- operators.
It seems they are only needed for the cnxk drivers; those drivers can probably be fixed in some other way.
>
> This split allows addressing each of the challenges above
> and provides distinct APIs for the distinct use cases.
> Examples:
> 1. Clang is able to optimize and improve __rte_raw_cksum
> (which uses RTE_PTR_ADD) by ~40% (100 bytes) to ~8x (1.5k bytes)
> TSC cycles/byte.
> 2. Refactoring discovered cases that dropped qualifiers (volatile)
> that the new API exposes.
>
> Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com>
> ---
A few minor details follow.
> static inline struct rte_mbuf *
> rte_mbuf_from_indirect(struct rte_mbuf *mi)
> {
> + RTE_ASSERT(mi);
Preferred: RTE_ASSERT(mi != NULL);
> return (struct rte_mbuf *)RTE_PTR_SUB(mi->buf_addr, sizeof(*mi) +
> mi->priv_size);
> }
>
> @@ -289,6 +290,7 @@ rte_mbuf_to_baddr(struct rte_mbuf *md)
> static inline void *
> rte_mbuf_to_priv(struct rte_mbuf *m)
> {
> + RTE_ASSERT(m);
Preferred: RTE_ASSERT(m != NULL);
> return RTE_PTR_ADD(m, sizeof(struct rte_mbuf));
> }
>
> --- a/lib/mempool/rte_mempool.h
> +++ b/lib/mempool/rte_mempool.h
> @@ -376,6 +376,7 @@ struct __rte_cache_aligned rte_mempool {
> static inline struct rte_mempool_objhdr *
> rte_mempool_get_header(void *obj)
> {
> + RTE_ASSERT(obj);
Preferred: RTE_ASSERT(obj != NULL);
> return (struct rte_mempool_objhdr *)RTE_PTR_SUB(obj,
> sizeof(struct rte_mempool_objhdr));
> }
> @@ -399,6 +400,7 @@ static inline struct rte_mempool
> *rte_mempool_from_obj(void *obj)
> static inline struct rte_mempool_objtlr *rte_mempool_get_trailer(void
> *obj)
> {
> struct rte_mempool *mp = rte_mempool_from_obj(obj);
> + RTE_ASSERT(mp);
Preferred: RTE_ASSERT(mp != NULL);
> return (struct rte_mempool_objtlr *)RTE_PTR_ADD(obj, mp-
> >elt_size);
> }
>
> @@ -1844,6 +1846,7 @@ rte_mempool_empty(const struct rte_mempool *mp)
> static inline rte_iova_t
> rte_mempool_virt2iova(const void *elt)
> {
> + RTE_ASSERT(elt);
> const struct rte_mempool_objhdr *hdr;
Preferred: RTE_ASSERT(elt != NULL);
Also, it might be preferable adding the RTE_ASSERT() here instead of above.
> hdr = (const struct rte_mempool_objhdr *)RTE_PTR_SUB(elt,
> sizeof(*hdr));
next prev parent reply other threads:[~2026-02-03 9:08 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 16:07 [PATCH v6] eal: RTE_PTR_ADD/SUB char* for compiler optimizations scott.k.mitch1
2026-01-14 21:56 ` [PATCH v7] " scott.k.mitch1
2026-01-16 11:39 ` Morten Brørup
2026-01-16 22:38 ` Scott Mitchell
2026-01-16 23:19 ` [PATCH v8] " scott.k.mitch1
2026-01-17 2:44 ` Stephen Hemminger
2026-01-17 21:07 ` Scott Mitchell
2026-01-17 21:03 ` [PATCH v9] " scott.k.mitch1
2026-01-18 6:12 ` Stephen Hemminger
2026-01-23 16:20 ` Scott Mitchell
2026-01-20 12:59 ` Morten Brørup
2026-01-23 16:27 ` [PATCH v10] " scott.k.mitch1
2026-01-24 7:58 ` Morten Brørup
2026-01-24 8:59 ` Scott Mitchell
2026-01-24 22:59 ` Scott Mitchell
2026-01-24 9:11 ` [PATCH v11] eal: RTE_PTR_ADD/SUB API improvements scott.k.mitch1
2026-01-25 11:11 ` scott.k.mitch1
2026-01-25 11:12 ` [PATCH v12] " scott.k.mitch1
2026-01-25 19:36 ` [REVIEW] " Stephen Hemminger
2026-01-25 22:24 ` Scott Mitchell
2026-01-26 8:19 ` Morten Brørup
2026-01-25 22:30 ` [PATCH v13] " scott.k.mitch1
2026-01-26 8:03 ` [PATCH v14] " scott.k.mitch1
2026-01-26 14:35 ` Morten Brørup
2026-01-26 21:29 ` Scott Mitchell
2026-01-27 5:11 ` Scott Mitchell
2026-01-27 2:02 ` [PATCH v15 0/2] " scott.k.mitch1
2026-01-27 2:02 ` [PATCH v15 1/2] eal: remove alloc_size from rte_lcore_var_alloc scott.k.mitch1
2026-01-27 2:02 ` [PATCH v15 2/2] eal: RTE_PTR_ADD/SUB API improvements scott.k.mitch1
2026-01-27 5:28 ` [PATCH v16 0/2] " scott.k.mitch1
2026-01-27 5:28 ` [PATCH v16 1/2] eal: remove alloc_size from rte_lcore_var_alloc scott.k.mitch1
2026-01-27 11:16 ` Mattias Rönnblom
2026-01-27 14:07 ` Stephen Hemminger
2026-01-27 5:29 ` [PATCH v16 2/2] eal: RTE_PTR_ADD/SUB API improvements scott.k.mitch1
2026-02-02 5:24 ` [PATCH v17 0/2] " scott.k.mitch1
2026-02-02 5:24 ` [PATCH v17 1/2] eal: remove alloc_size from rte_lcore_var_alloc scott.k.mitch1
2026-02-03 8:24 ` Morten Brørup
2026-02-03 9:48 ` David Marchand
2026-02-02 5:24 ` [PATCH v17 2/2] eal: RTE_PTR_ADD/SUB API improvements scott.k.mitch1
2026-02-03 9:08 ` Morten Brørup [this message]
2026-02-03 16:24 ` Scott Mitchell
2026-02-03 9:51 ` David Marchand
2026-02-03 16:25 ` Scott Mitchell
2026-02-03 21:18 ` [PATCH v18 0/2] " scott.k.mitch1
2026-02-03 21:18 ` [PATCH v18 1/2] eal: remove alloc_size from rte_lcore_var_alloc scott.k.mitch1
2026-02-03 21:18 ` [PATCH v18 2/2] eal: RTE_PTR_ADD/SUB API improvements scott.k.mitch1
2026-02-04 2:46 ` [PATCH v19] " scott.k.mitch1
2026-02-04 5:20 ` Scott Mitchell
2026-02-04 6:12 ` [PATCH v20] " scott.k.mitch1
2026-02-04 22:47 ` Morten Brørup
2026-02-05 6:53 ` Scott Mitchell
2026-02-05 7:03 ` [PATCH v21] " scott.k.mitch1
2026-02-05 7:50 ` Morten Brørup
2026-02-06 1:04 ` Scott Mitchell
2026-02-06 1:01 ` [PATCH v22] " scott.k.mitch1
2026-02-06 4:28 ` [PATCH v23] " scott.k.mitch1
2026-02-06 16:09 ` Stephen Hemminger
2026-02-07 1:45 ` [PATCH v24] " scott.k.mitch1
2026-01-27 20:28 ` [REVIEW] " Stephen Hemminger
2026-02-02 5:17 ` Scott Mitchell
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=98CBD80474FA8B44BF855DF32C47DC35F656E6@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=scott.k.mitch1@gmail.com \
--cc=stephen@networkplumber.org \
/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