RE: [RFC v2] non-temporal memcpy

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<snip>
> 
> > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > Sent: Wednesday, 27 July 2022 19.38
> >
> 
> [...]
> 
> > >
> > > > > Yes, x86 needs 16B alignment for NT load/stores But that's
> > supposed
> > > > to be arch
> > > > > specific limitation, that we probably want to hide, no?
> > >
> > > Correct. However, optional hints for optimization purposes will be
> > available.
> > > And it is up to the architecture specific implementation to make the
> > best use
> > > of these hints, or just ignore them.
> > >
> > > > > Inside the function can check alignment of both src and dst and
> > > > decide should it
> > > > > use NT load/store instructions or just do normal copy.
> > > > IMO, the normal copy should not be done by this API under any
> > > > conditions. Why not let the application call memcpy/rte_memcpy
> > > > when the NT copy is not applicable? It helps the programmer to
> > understand
> > > > and debug the issues much easier.
> > >
> > > Yes, the programmer must choose between normal memcpy() and non-
> > > temporal rte_memcpy_nt(). I am offering new functions, not modifying
> > > memcpy() or rte_memcpy().
> > >
> > > And rte_memcpy_nt() will silently fall back to normal memcpy() if
> > non-
> > > temporal copying is unavailable, e.g. on POWER and RISC-V
> > architectures,
> > > which don't have NT load/store instructions.
> > I am talking about a scenario where the application is being ported
> > between architectures. Not everyone knows about the capabilities of
> > the architecture. It is better to indicate upfront (ex: compilation
> > failures) that a certain feature is not supported on the target
> > architecture rather than the user having to discover through painful
> > debugging.
> 
> I'm considering rte_memcpy_nt() a performance optimized variant of
> memcpy(), where the performance gain is less cache pollution. Thus, silent
> fallback to memcpy() should suffice.
> 
> Other architecture differences also affect DPDK performance; the inability to
> perform non-temporal load/store just one more to the (undocumented) list.
> 
> Failing at build time if NT load/store is unavailable by the architecture would
> prevent the function from being used by other DPDK libraries, e.g. by the
> rte_pktmbuf_copy() function used by the pdump library.
The other libraries in DPDK need to provide NT versions as the libraries need to cater for not-NT use cases as well. i.e. we cannot hide a NT copy under rte_pktmbuf_copy() API, we need to have rte_pktmbuf_copy_nt()

> 
> I don't oppose to your idea, I just don't have any idea how to reasonably
> implement it. So I'm trying to defend why it is not important.
I am suggesting that the applications could implement #ifdef depending on the architecture.