On Wed, 27 Jul 2022, 21:53 Honnappa Nagarahalli, <
Honnappa.Nagarahalli@arm.com> wrote:

> <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.
>
I assume that it would be a pre-processor flag defined (or not) on DPDK
side and application doing #ifdef based on it?

Another way to achieve this would be to use #warning directive (see [1])
inside DPDK when the generic fallback is taken.

Also isn't the argument on memcpy_nt capability query not a more general
one, that is how would/should application query DPDK's capabilities when
run or compiled?

[1] https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html

>