> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Sunday, 16 January 2022 17.34 > > 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.
I wonder if that is still the case? Otherwise, DPDK is probably full of obsolete optimizations, which should be eliminated like this: http://inbox.dpdk.org/dev/20210918114930.245387-1-m...@gms.tf/
