Re: [RFC v2] eal: provide option to use compiler memcpy instead of RTE

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2024-05-28 16:59, Stephen Hemminger wrote:
> On Tue, 28 May 2024 10:19:15 +0200
> Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> 
>>>    
>>
>> I've tested this patch some with DSW micro benchmarks, and the result is
>> a 2.5% reduction of the DSW+testapp overhead with cc/libc memcpy. GCC 11.4.
>>
>> We've also run characteristic test suite of a large, real world app.
>> Here, we saw no effect. GCC 10.5.
>>
>> x86_64 in both cases (Skylake and Raptor Lake).
>>
>> Last time we did the same, there were a noticeable performance
>> degradation in both the above cases.
>>
>> This is not a lot of data points, but I think it we should consider
>> making the custom RTE memcpy() implementations optional in the next
>> release, and if no-one complains, remove the implementations in the next
>> release.
> 
> Lets go farther.
> 
> 1. Announce that rte_memcpy will be marked deprecated in 24.11 release
> 
> 2. In 24.11 do a global replace of rte_memcpy on the tree.
>     And mark rte_memcpy as deprecated.
> 
> 3. In 25.11 it can go away.

If/when rte_memcpy.h is just a tiny memcpy() wrapper, the maintenance 
burden is pretty much eliminated.

Keeping it around will allow for older applications to compile against 
newer DPDK version.

You can always discourage its use in the API documentation.

Also, hopefully, some day, we will have a non-temporal memcpy(), and 
those functions needs a home.