DPDK patches and discussions
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Huichao Cai <chcchc88@163.com>,
	dev@dpdk.org, konstantin.ananyev@intel.com,
	David Marchand <david.marchand@redhat.com>
Subject: Re: [PATCH] ip_frag: replace the rte memcpy with memcpy
Date: Fri, 24 Jun 2022 18:25:10 +0100	[thread overview]
Message-ID: <3ae8f3d7-5578-d841-9458-24d6f203da0d@yandex.ru> (raw)
In-Reply-To: <20220622193520.16e7c2e5@hermes.local>

23/06/2022 03:35, Stephen Hemminger пишет:
> On Wed, 22 Jun 2022 23:49:39 +0100
> Konstantin Ananyev <konstantin.v.ananyev@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



  parent reply	other threads:[~2022-06-24 17:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 14:09 Huichao Cai
2022-06-21 15:11 ` David Marchand
2022-06-22 22:49 ` Konstantin Ananyev
2022-06-23  2:35   ` Stephen Hemminger
2022-06-23 14:24     ` David Marchand
2022-06-24 17:25     ` Konstantin Ananyev [this message]
2022-06-27 11:12       ` Liang Ma
2022-06-23 14:26 ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ae8f3d7-5578-d841-9458-24d6f203da0d@yandex.ru \
    --to=konstantin.v.ananyev@yandex.ru \
    --cc=chcchc88@163.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).