Re: [RFC v2] non-temporal memcpy

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 29 Jul 2022 12:13:52 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:

> Sorry, missed that part.
> 
> >   
> > > Another question - who will do 'sfence' after the copying?
> > > Would it be inside memcpy_nt (seems quite costly), or would
> > > it be another API function for that: memcpy_nt_flush() or so?  
> > 
> > Outside. Only the developer knows when it is required, so it wouldn't make any sense to add the cost inside memcpy_nt().
> > 
> > I don't think we should add a flush function; it would just be another name for an already existing function. Referring to the required
> > operation in the memcpy_nt() function documentation should suffice.
> >   
> 
> Ok, but again wouldn't it be arch specific?
> AFAIK for x86 it needs to boil down to sfence, for other architectures - I don't know.
> If you think there already is some generic one (rte_wmb?) that would always produce
> correct instructions - sure let's use it. 
>  
>  

It makes sense in a few select places to use non-temporal copy.
But it would add unnecessary complexity to DPDK if every function in DPDK that could
cause a copy had a non-temporal variant.

Maybe just having rte_memcpy have a threshold (config value?) that if copy is larger than
a certain size, then it would automatically be non-temporal.  Small copies wouldn't matter,
the optimization is more about not stopping cache size issues with large streams of data.