RE: [RFC v2] non-temporal memcpy

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> +TO: @Honnappa, we need input from ARM
> 
> > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > Sent: Friday, 29 July 2022 21.49
> > >
> > > > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > > > Sent: Friday, 29 July 2022 14.14
> > > >
> > > >
> > > > 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.
> > > >
> > >
> > > DPDK has generic functions to wrap architecture specific stuff like
> > memory barriers.
> > >
> > > Because they are non-temporal stores, I suspect that rte_mb() is
> > required before reading the data from the location it was copied to.
> > > Ensuring that STORE operations are ordered (rte_wmb) might not
> > suffice. However, I'm not a CPU expert, so I will seek advice from
> > > more qualified people in the community on this.
> >
> > I think for IA sfence is enough, see citation below,
> > for other architectures - no idea.
> > What I am trying to say - it needs to be the *same* function on all
> > archs we support.
> 
> Now I get it: rte_wmb() might be appropriate on x86, but if any other architecture requires something else, we should add a new
> common function for flushing, e.g. rte_memcpy_nt_flush().

Yep, that was my thought.