23/06/2022 03:35, Stephen Hemminger пишет:
On Wed, 22 Jun 2022 23:49:39 +0100
Konstantin Ananyev <konstantin.v.anan...@yandex.ru> wrote:
@@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr
*dst,
const struct rte_ipv4_hdr *src, uint16_t header_len,
uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
{
- rte_memcpy(dst, src, header_len);
+ memcpy(dst, src, header_len);
I am fine with replacements in test and inside the lib, for cases
where 'len' parameter is constant value.
Though as I said before, here 'header_len' is not a constant value.
Are you sure it will not introduce any performance regression?
Do you have any performance tests. The ip header options are very small.
From my experience - usually it is not about how big or small amount
we need to copy. It is about can compiler evaluate 'size' parameter
for memcpy() at compilation time or not.
If it can, great - it will most likely replace memcpy()
with some really well optimized code.
If not it has to generate a proper call to actual
memcpy() function. Which again, can be well optimized, but the
overhead of the function call itself can still be noticeable,
specially for small copies.
Anyway, as I can see, David already integrated these changes anyway.
So now, we'll have to wait and see would anyone complain or not.
About performance testing, the only one I am aware about:
examples/ip_fragmentation
Konstantin
