RE: [PATCH 00/61] reduce use of rte_memcpy

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Thursday, 20 August 2026 15.08
> 
> > > > About replacing rte_memcpy with memcpy()...
> > > >
> > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > > Sent: Thursday, 20 August 2026 07.12
> > > > >
> > > > > The DPDK function rte_memcpy() only exists as an optimization
> > > > > for shortcomings in performance of libc memcpy() on some
> platforms.
> > > >
> > > > Yes, and those platforms should benefit from it.
> > > >
> > > > E.g. the vhost performance improvements for Haswell and Broadwell
> > > [1].
> > > > Where similar performance improvements implemented in the
> relevant
> > > > compilers (GCC, Clang, MSVC)?
> > > >
> > > > [1]:
> > > >
> > >
> >
> https://github.com/DPDK/dpdk/commit/4b42e90ef0e421dc777f2b2e377eb237cd
> > > > 3675fa
> > > >
> > > > IMO, performance should remain a high priority for DPDK.
> > >
> > > As I can read the series, good few of them do remove rte_memcpy
> from
> > > the CP,
> > > where it is clearly irrelevant.
> >
> > Agree!
> >
> > > For those on the DP, at least for some of them we can run perf
> tests:
> > > let say for hash we do have perf_autotest which can be used to
> measure
> > > the
> > > perf diff. If there is none, or neglectable - then no point to keep
> > > rte_memcpy here.
> >
> > Unless that perf test is run on all platforms, the result only shows
> perf diff on
> > the tested platforms.
> 
> How this patch differs from all others?

It removes something that is supposed to be a performance optimization.
E.g. reference [1] fixes vhost performance on Haswell and Broadwell; if we remove rte_memcpy(), the performance of that use case on those CPU types might drop back to being bad.

> For each and every change we made in DPDK, to ensure that there is no
> perf regression introduced we rely on:
> 1) CI auto testing
> 2) manual testing from some platform vendors (once per release cycle)
> 3) good will of submitter to test the changes he produces as much as
> possible
> Obviously, yes we are not testing on each possible platform and yes, in
> theory
> some regressions can sneak in unseen.
> But that could happen with other patches too, so from my perspective -
> we just need our usual testing procedure here, if it shows no
> regression,
> the patch is good to go in.
> 
> > >
> > > >
> > > > > 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 wherever possible.
> > > >
> > > > I think this is the only substantial benefit of replacing
> > > rte_memcpy() with
> > > > memcpy()!
> > > > Could we reap this benefit by having special builds for such
> tools,
> > > where
> > > > rte_memcpy() is modified to use memcpy() instead?
> > > > Then we wouldn't have to compromise on performance.
> > > >
> > > > Also, rte_memcpy() used to have a pragma disabling bounds checks
> due
> > > to some
> > > > Intel drivers using [0] instead of []; the pragma was removed
> from
> > > rte_memcpy()
> > > > when the Intel drivers were fixed.
> > > > I'm not sufficiently familiar with analysis/test tools to say
> what
> > > they can detect
> > > > when using memcpy() instead of the copy methods used by
> rte_memcpy().
> > > >
> > > > >
> > > > > This patch series introduces a coccinelle script to find
> > > > > calls to rte_memcpy() where size is fixed, and change them to
> > > > > regular memcpy(). This was the starting point for this cleanup.
> > > > >
> > > > > There is also some cleanups to include rte_memcpy.h and
> string.h
> > > > > where needed. Often the includes were happening by some other
> > > > > header. And also removal of rte_memcpy.h where no longer
> needed.
> > > > >
> > > > > The result is a 46% reduction in use of rte_memcpy.
> > > > > The remaining rte_memcpy can be cleaned up later:
> > > > >  - drivers with active maintenance (like mlx5);
> > > > >  - changes to rte_memcpy which need benchmarking;
> > > > >  - test code for rte_memcpy can be removed as last step.
> > > > >
> > > > > No functional change, no warnings in all compilers including
> LTO.
> > > >
> > > > memcpy() does not always use inline vector instructions for fixed
> > > size copy [2].
> > > >
> > > > [2]:
> > > >
> > https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35F659B8@sma
> > > > rtserver.smartshare.dk/
> > > >
> > > >
> > > > Another disadvantage of rte_memcpy() is the lack of developer
> > > guidance.
> > > > It is not well documented when to use rte_memcpy() and when to
> use
> > > memcpy().
> > > > We discussed something similar on the Tech Board meeting
> yesterday;
> > > it is not
> > > > well documented when to use which type of "ring" (normal, RTS,
> HTS),
> > > so maybe
> > > > we could remove one of them.
> > > > But removing an option is not an improvement, if the removed
> option
> > > would
> > > > have been the better choice for some use cases.
> > > >
> > > > PS: The general guidance for rte_memcpy() usage is something
> like:
> > > > rte_memcpy() only in fast path,
> > > > memcpy() everywhere else,
> > > > assignment "=" when copying fixed size structures.
> > >
> > > I suppose for te_memcpy() we can be even more strict:
> > > Use it only for DP, and only after measurement, that shows
> > > clear perf improvement over ordinal memcpy().
> > > Alnd also ask contributors to document it (in the comments), i.e.:
> > > /* on <platform testsed> rte_memcpy() gives X% perf boost when
> doing
> > > ...*/
> > > rte_memcpy(...);
> >
> > Disagree!
> > DPDK has performance optimized libs and functions.
> > Developers should not need to document that using a DPDK function is
> faster
> > than using a libc function.
> > We don't require perf measurements for using DPDK rte_hash instead of
> libc
> > hashmap.
> 
> Not sure what libc hashmap you are talking about?
> AFAIK such thing doesn't exist.. or you talking about c++ maps?

Sorry, it was hashmap in libmba. Bad example.

> If so, then I think the analogy is not correct.
> Why not to remember another example when we get rid of our own
> hand-written atomics and barriers in favor of using atomics ones.

Great example.
IIRC, many people were involved in this effort, and it was thoroughly reviewed for correctness and performance.
And some of the old atomics still ended up remaining for performance reasons.
And C11 atomics is still not the default for DPDK.

That level of effort doesn't seem to be on the table for migrating from rte_memcpy() to memcpy().
The vibe I'm sensing is more like: "Compilers' built-in memcpy() is just as good as rte_memcpy(), so rte_memcpy() has outlived itself."
And maybe that statement is true, but I just don't feel confident about it.
Perhaps I'm just being too cautious here.

> 
> >
> > I agree about not using rte_memcpy() in the control plane.
> > And I support Stephen's effort to clean this up.
> >
> > But why the eagerness to avoid using rte_memcpy() in the fast path?
> 
> I think we are not talking about 'avoiding' but about 'limiting'.
> There are many cases, when people use rte_memcpy() just because
> 'it is used in other places, so it is probably better'
> In general memcpy()  and rte_memcpy() have same syntax,
> provide same functionality, plus CC vendors made a good progress in
> optimizing memcpy(),
> so now for many cases it provides nearly the same or better
> performance.
> I think no-one forces to replace rte_memcpy() in places where it does
> provide better results,
> but for the cases when there is no perf difference, I think memcpy()
> should have precedence.

You prefer memcpy() over rte_memcpy() when they perform similarly.
That's your preference.
And you are not alone with that preference.

When they perform similarly, I prefer rte_memcpy().
And it seems I'm in the minority with that preference.

If we set up barriers to using rte_memcpy(), we'll see even more custom implementations, such as in the ring [3] and stack [4] libraries.
But maybe (and I'm being serious here!) that might be a good thing after all:
Use memcpy() for general cases, and use individually specialized versions for special use cases.
(Possibly using pragmas to tweak memcpy() for some of those special use cases.)

[3]: https://elixir.bootlin.com/dpdk/v26.07/source/lib/ring/rte_ring_elem_pvt.h#L65
[4]: https://elixir.bootlin.com/dpdk/v26.07/source/lib/stack/rte_stack_std.h#L40

Here's an alternative path...
PowerPC rte_memcpy() uses memcpy() for fixed size copies [5].
And ARM makes the rte_memcpy() implementation build time optional [6].
We could start softly by copying these two concepts to X86 architecture.

[5]: https://elixir.bootlin.com/dpdk/v26.07/source/lib/eal/ppc/include/rte_memcpy.h#L80
[6]: https://elixir.bootlin.com/dpdk/v26.07/source/lib/eal/arm/include/rte_memcpy_64.h#L13