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

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> > > > > > > > > +	/* 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 think that should be measurable too: whole binary  and/or hot path function size reduction, etc. 

> 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.

Ok, then I suggest we do some measurements first, before going forward with it. 

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