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

Mattias Rönnblom hofors at lysator.liu.se
Fri May 31 07:19:41 CEST 2024


On 2024-05-28 17:09, Bruce Richardson wrote:
> On Tue, May 28, 2024 at 07:59:36AM -0700, Stephen Hemminger wrote:
>> On Tue, 28 May 2024 10:19:15 +0200
>> Mattias Rönnblom <hofors at 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.
> 
> While I'd like us to be able to do so, I believe that to be premature. We
> need to see where/if there are regressions first, and see about fixing
> them.
> 
> /Bruce

Should I turn this RFC into a PATCH?

Is use_cc_memcpy a good name for the configuration parameter?



More information about the dev mailing list