This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Intel's new rte_memcpy()


I am hoping for some feedback and advice for me as an application developer.

Intel have recently posted a couple of memcpy() implementations and
suggested that these have significant advantages for networking
applications. There is one for Sandy Bridge and one for Haswell. The
proposal is that networking application developers would statically
link one or both of these into their applications instead of
dynamically linking with glibc. The proposal is part of their Data
Plane Development Kit (

They explain it much better than I do:

and their code is here:

My question to the list is this:

Should networking application developers adopt Intel's custom
implementation if (like me) they are absolutely dependent on good and
consistent performance of memcpy on all recent hardware (>= Sandy
Bridge) and Linux distributions? (and then -- what to do about

I have done some cursory benchmarks with cachebench:

... with a correction to the rte_memcpy on Haswell results:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]