Re: [PATCH v2 00/68] reduce use of rte_memcpy

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Aug 21, 2026 at 12:23:55PM -0700, Stephen Hemminger wrote:
> The DPDK function rte_memcpy() only exists as an optimization
> for shortcomings in performance of libc memcpy() on some platforms.
> Many platforms have no special rte_memcpy() and just use memcpy().
> 
> But many analysis and test tools know that memcpy() is a special
> case and check for overwrite, bounds errors etc. Therefore memcpy()
> should be preferred where ever possible.
> 
> This patch series introduces a coccinelle script to find
> calls to rte_memcpy() where size is fixed, and change them to
> regular memcpy(). Many of the patch series is just the results
> of that script.
> 
> There is also some cleanups to include rte_memcpy.h where it
> was not being done before; the include was happening by some other header.
> And also removal of rte_memcpy.h where no longer needed.
> 
> The result is a 45% reduction in use of rte_memcpy (1008 call
> sites down to 551). The leftover cases are places where rte_memcpy
> is used in data path; and test code for rte_memcpy.
> 
> v2:
>   - reorder the series so it bisects cleanly: the patches adding
>     the missing includes of rte_memcpy.h now come first, before
>     any patch that removes an include or replaces a call. In v1
>     those were at the end of the series, so intermediate commits
>     could fail to build.
>   - move the documentation patch describing when to use
>     rte_memcpy() to the front of the series, so the rationale for
>     the rest of the changes is established first.
> 

I like this series, and the rework of the order in v2 is ok, but I actually
think the patchset should be split - at least into 2, if not more.

The patches removing the unnecessary include of rte_memcpy from C files
should be split out into a separate patchset. There are a number of these
in the series, and many have an incorrect patch title and description, a
couple of which I flagged (I was working backward through the patchset -
don't ask why, cos I don't know!). That patchset is a trivial review and
merge case, since if it builds it's fine.

That then cuts down the rest of the set by a bit, making it more trackable.
If possible, I'd actually like to see another patchset separated out to
cover the case where you replace all constant-sized rte_memcpy calls, which
use sizeof, with regular memcpy. Having all patches doing the same thing
again makes it trivial to review and ack.

That would then leave the rest of the changes which require more
examination - where we are replacing a non-constant copy using rte_memcpy
with a memcpy. That's where the focus needs to be for review.

Just my 2c. I think having a 68-patch set in one is too big.

/Bruce