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
