RE: [PATCH] eal/x86: optimize memcpy of small 64-byte blocks

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

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Wednesday, 5 August 2026 19.16
> 
> > > > > > > > +	/* Common way for small copy size of 64-byte blocks.
> > > > > Unlikely, so
> > > > > > > constant size only */
> > > > > > > > +	if (__rte_constant(n) && (n & 63) == 0 && n <=
> > > > > > > RTE_MEMCPY_BLOCK_64_MAX) {
> > > > > > > > +		void *ret = dst;
> > > > > > > > +
> > > > > > >
> > > > > > > Maybe just let compiler decide, it will generate vector
> > > > > instructions in
> > > > > > > most cases.
> > > > > > >
> > > > > > > 	if (__rte_constant(n))
> > > > > > > 		return mempcpy(dst, src, n);
> > > > > >
> > > > > > Maybe in most, but not in all:
> > > > > > https://godbolt.org/z/KvdKqT5rY
> > > > >
> > > > > With '-mavx' or '-mavx512f' it looks like it does for your
> sample
> > > code.
> > > >
> > > > It also does with -msse4.2 when SZ is reduced to 256 bytes.
> > > > Clang switches to inline when SZ is reduced to 128 bytes.
> > > >
> > > > It seems the compiler has a threshold for when to inline and when
> to
> > > call the C
> > > > library's memcpy subroutine.
> > > > The threshold depends on both copy size and vector register size.
> > > > And it is compiler dependent.
> > >
> > > I think there are compiler options to specify desired threshold
> values.
> > > Let say for gcc there is  ' -mmemcpy-strategy=strategy'.
> > > For that example in that particular case
> > > -mmemcpy-strategy=vector_loop:512:align,loop:-1:align
> > > generates sse loads/stores.
> > > Might be we can exploit it somehow?
> >
> > That could give us higher granularity/control over memcpy for
> individual
> > memcpy instances; might be useful for hot code paths where we have
> more
> > knowledge about the copy operation than the compiler can infer.
> > However, pragmas are discouraged in DPDK, and this looks like a very
> similar
> > path.
> 
> Well, right now  rte_memcpy.h is 700+ lines and keeps growing.
> Considering that probably pragmas are not that bad.
> Of course, pragmas have their own issues and it is hard to ensure that
> they will produce same code between different compilers/versions, etc.
> 
> > > I am not really happy that our home-brewed memcpy code-block keeps
> > > growing,
> > > while we keep talking that it would be good to eliminate it
> completely.
> >
> > I agree in principle.
> > However, this rte_memcpy() optimization is for the pile/mempool
> optimizations
> > I'm working on, so there is a specific use case motivating the added
> code.
> 
> I understand that you probably have some specific use-case in mind.
> BTW for this optimization you mentioned above: what is the gain with
> these changes?

IMO, the primary benefit is the much simpler (and smaller) assembly output due to avoiding the address alignment check (and the resulting duplicated code).

I haven't measured the performance gain.
Based on the perf gain in a previous mempool optimization patch [1], it seems avoiding the address alignment check shaves ~2 cycles off the copy operation (for cache-to-cache copy).
I expect that the same gain (from avoiding the address alignment check) applies here.

[1]: https://patchwork.dpdk.org/project/dpdk/patch/20260521185631.116046-1-mb@smartsharesystems.com/