On Fri, Sep 11, 2026 at 11:06:04AM +0100, Bruce Richardson wrote:
> 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.
s/trackable/tractable/
> 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.
>
Further suggestion - can you just do up a 2 patch set with the cocci script
as patch 1, and a single replacement patch from running it as patch 2 (or
one patch per app/lib/drivers/...)?
