> From: Konstantin Ananyev [mailto:[email protected]] > 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/[email protected]/
