On Mon, Jan 12, 2026 at 11:09 AM Bruce Richardson
<[email protected]> wrote:
>
> On Mon, Jan 12, 2026 at 10:40:59AM -0500, [email protected] wrote:
> > From: Scott Mitchell <[email protected]>
> >
> > Modify RTE_PTR_ADD and RTE_PTR_SUB to use char* pointer arithmetic
> > instead of uintptr_t casts. Benefits of this approach:
> > - API compatibility: works for both integer and pointer inputs
> > - Retains simple macros: no pragmas, no _Generic
> > - Enables compiler optimizations: Clang now can unroll and vectorize
> > pointer loops, and GCC still can apply these optimizations.
> >
> > Example use case which benefits is __rte_raw_cksum. Performance
> > results from cksum_perf_autotest on Intel Xeon (Cascade Lake,
> > AVX-512) built with Clang 18.1 (TSC cycles/byte):
> >   Block size    Before    After    Improvement
> >          100      0.40     0.24        ~40%
> >         1500      0.50     0.06        ~8x
> >         9000      0.49     0.06        ~8x
> >
> > Signed-off-by: Scott Mitchell <[email protected]>
> > ---
>
>
> The macro implementation LGTM
>
> Acked-by: Bruce Richardson <[email protected]>
>
> Couple of comments on the unit tests inline below. Most are only
> suggestions, so feel free to ignore if you think they aren't worth
> considering.

Thanks for the review! I will need a v6 as CI detected
compiler/environment combos
with errors. I'm trying to thread the needle to find a way to preserve
APIs and enable clang optimizations.

> Given all the typecasting in the macros, I don't like the casting to
> uintptr_t when checking the return values. Maybe use (void *) on the value
> being compared-with instead.
>
> A suggestion: can you maybe put at the top:
>
> #define test_initval 0x1000
> #define test_increment 100
> #define test_retval ((void *)0x1064))
>
> and use those everywhere rather than the hard-coded constants?

Sounds good!

> Maybe define a new set of macros for small sized ints? Or else just use 100
> and 50 generally, rather than 0x1064? The test should be just as good,
> right?

I'll use macros for different sizes to catch potential for unexpected
truncation.

> Very comprehensive set of tests, thanks.

No problem!

Reply via email to