On Sun, 16 Jan 2022 09:33:19 -0500 Luc Pelletier <lucp.at.w...@gmail.com> wrote:
> As a side note, and to follow up on Stephen's indication that this is > 'performance critical code', I think it might be worthwhile to > revisit/revalidate the current implementation of rte_memcpy. There's a > good thread here that mentions rte_memcpy, and its performance on at > least one platform/architecture combination is far from being the > best: > > https://github.com/microsoft/mimalloc/issues/201 > > It seems like enhanced rep movsb could be faster on more recent CPUs, > but that's currently not being used in the current implementation of > rte_memcpy. > > I understand some of this may not be directly related to this patch, > but whoever looks at this patch might want to provide their thoughts > on whether updating rte_memcpy would be worthwhile? I suspect looking > at all current public implementations of memcpy (libc, microsoft, > compilers builtin implementations, etc.) might help in making > improvements. I would prefer that rte_memcpy did not exist at all. Instead the system library should always be used. It is only exists because some architectures have slower code in glibc.
