<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Jul 2022, 21:53 Honnappa Nagarahalli, <<a href="mailto:Honnappa.Nagarahalli@arm.com" rel="noreferrer noreferrer" target="_blank">Honnappa.Nagarahalli@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><snip><br>
> <br>
> > From: Honnappa Nagarahalli [mailto:<a href="mailto:Honnappa.Nagarahalli@arm.com" rel="noreferrer noreferrer noreferrer" target="_blank">Honnappa.Nagarahalli@arm.com</a>]<br>
> > Sent: Wednesday, 27 July 2022 19.38<br>
> ><br>
> <br>
> [...]<br>
> <br>
> > ><br>
> > > > > Yes, x86 needs 16B alignment for NT load/stores But that's<br>
> > supposed<br>
> > > > to be arch<br>
> > > > > specific limitation, that we probably want to hide, no?<br>
> > ><br>
> > > Correct. However, optional hints for optimization purposes will be<br>
> > available.<br>
> > > And it is up to the architecture specific implementation to make the<br>
> > best use<br>
> > > of these hints, or just ignore them.<br>
> > ><br>
> > > > > Inside the function can check alignment of both src and dst and<br>
> > > > decide should it<br>
> > > > > use NT load/store instructions or just do normal copy.<br>
> > > > IMO, the normal copy should not be done by this API under any<br>
> > > > conditions. Why not let the application call memcpy/rte_memcpy<br>
> > > > when the NT copy is not applicable? It helps the programmer to<br>
> > understand<br>
> > > > and debug the issues much easier.<br>
> > ><br>
> > > Yes, the programmer must choose between normal memcpy() and non-<br>
> > > temporal rte_memcpy_nt(). I am offering new functions, not modifying<br>
> > > memcpy() or rte_memcpy().<br>
> > ><br>
> > > And rte_memcpy_nt() will silently fall back to normal memcpy() if<br>
> > non-<br>
> > > temporal copying is unavailable, e.g. on POWER and RISC-V<br>
> > architectures,<br>
> > > which don't have NT load/store instructions.<br>
> > I am talking about a scenario where the application is being ported<br>
> > between architectures. Not everyone knows about the capabilities of<br>
> > the architecture. It is better to indicate upfront (ex: compilation<br>
> > failures) that a certain feature is not supported on the target<br>
> > architecture rather than the user having to discover through painful<br>
> > debugging.<br>
> <br>
> I'm considering rte_memcpy_nt() a performance optimized variant of<br>
> memcpy(), where the performance gain is less cache pollution. Thus, silent<br>
> fallback to memcpy() should suffice.<br>
> <br>
> Other architecture differences also affect DPDK performance; the inability to<br>
> perform non-temporal load/store just one more to the (undocumented) list.<br>
> <br>
> Failing at build time if NT load/store is unavailable by the architecture would<br>
> prevent the function from being used by other DPDK libraries, e.g. by the<br>
> rte_pktmbuf_copy() function used by the pdump library.<br>
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()<br>
<br>
> <br>
> I don't oppose to your idea, I just don't have any idea how to reasonably<br>
> implement it. So I'm trying to defend why it is not important.</blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am suggesting that the applications could implement #ifdef depending on the architecture.<br></blockquote></div></div><div dir="auto">I assume that it would be a pre-processor flag defined (or not) on DPDK side and application doing #ifdef based on it?</div><div dir="auto"><br></div><div dir="auto">Another way to achieve this would be to use #warning directive (see [1]) inside DPDK when the generic fallback is taken.</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">[1] <a href="https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html" rel="noreferrer noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html</a></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>