[PATCH v5 00/32] replace use of rte_memcpy() with fixed size

[Mattias Rönnblom]

On 2024-05-27 01:32, Stephen Hemminger wrote:
> On Sun, 26 May 2024 16:51:52 +0200
> Mattias Rönnblom <hofors at 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.