On Wed, 27 Jul 2022, 21:53 Honnappa Nagarahalli, < honnappa.nagaraha...@arm.com> wrote:
> <snip> > > > > > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@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 >
