On 2024-05-27 01:32, Stephen Hemminger wrote:
On Sun, 26 May 2024 16:51:52 +0200
Mattias Rönnblom <hof...@lysator.liu.se> wrote:
This does not change the resulting binary on almost all architectures
because x86 version of intrisics and glibc are the same, and
other architectures were using __builtin_constant_p().
The main benefit is that analysis tools like fortify, Coverity, and ASAN
analyzers can check these memcpy's. A recent example is that
on Ubuntu 22.04 detected undefined use of memcpy such as:
memcpy(dst, NULL, 0)
Would it be possible to instead have a build mode where rte_memcpy() is
*always* delegating to memcpy(), and run these tools on that configuration?
It seems easier to just always using rte_memcpy() in DPDK code, then let
the platform (not the programmer) choose whatever is most appropriate.
I would prefer that rte_memcpy be laid to rest and go away.
Sounds good, but is this piecemeal approach the way to do it. Why ask
DPDK programmers to memorize rules about when to use memcpy() and when
not to, when that can be coded into the rte_memcpy() implementation.
Worst case, when people have learned those rules, we'll change them.
"Use rte_memcpy() only for large copies," or whatever it might be.
Use rte_memcpy() across the board until memcpy() is a complete
replacement, for every use case, for every CPU/compiler/OS.
Applications using DPDK will benefit from any heuristics encoded into
rte_memcpy.h. The won't run coccinelle script.
It never had a reason to be there.
Sure, it did. Historically it has had better performance, up to at least
fairly recently that seemed still be the case. I've patched DPDK to
replace rte_memcpy() with memcpy() several times, and run with
real-world apps. The result is always the same.
The compiler is in a better position than DPDK to implement memcpy(), so
eventually the compiler will win.
