On 2022-08-09 19:24, Morten Brørup wrote:
From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: Tuesday, 9 August 2022 17.26
On Tue, 9 Aug 2022 11:46:19 +0200
Morten Brørup <m...@smartsharesystems.com> wrote:
I don't think memcpy() functions should have alignment
requirements.
That's not very practical, and violates the principle of least
surprise.
I didn't make the CPUs with these alignment requirements.
However, I will offer optimized performance in a generic NT memcpy()
function in the cases where the individual alignment requirements of
various CPUs happen to be met.
Rather than making a generic equivalent memcpy function, why not have
something which only takes aligned data.
Our application is copying data not meeting x86 NT load alignment requirements
(16 byte), so the function must support that. Specifically, our application is
copying complete or truncated IP packets excl. the Ethernet and VLAN headers,
i.e. offset by 14, 18 or 22 byte from the cache line aligned packet buffer.
Sure, but you can use regular loads for the non-aligned parts, and the
you continue to use NT load for the rest of the data. I suspect there is
no point in doing NT loads for data on the same cache line that you've
done regular loads for, so you might as well treat the alignment
requirements as 64 byte, not 16.
And to avoid user confusion
change the name to be something not suggestive of memcpy.
Maybe rte_non_cache_copy()?
Want to avoid the naive user just doing s/memcpy/rte_memcpy_nt/ and
expect
everything to work.
I see the risk you point out here... But it's not advertised in presentations,
whitepapers and elsewhere like rte_memcpy() having much better performance than
classic memcpy(), which might lead to that misconception. So the probability
should be low.
