From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
dev@dpdk.org, olivier.matz@6wind.com,
Pablo de Lara <pablo.de.lara.guarch@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3] mempool: replace c memcpy code semantics with optimized rte_memcpy
Date: Thu, 7 Jul 2016 14:51:24 +0100 [thread overview]
Message-ID: <577E5E5C.2050000@intel.com> (raw)
In-Reply-To: <577D3006.1080504@intel.com>
On 7/6/2016 5:21 PM, Ferruh Yigit wrote:
> On 7/5/2016 3:09 PM, Ferruh Yigit wrote:
>> On 7/5/2016 2:13 PM, Jerin Jacob wrote:
>>> On Tue, Jul 05, 2016 at 07:32:46PM +0800, Yuanhan Liu wrote:
>>>> On Tue, Jul 05, 2016 at 09:43:03AM +0100, Ferruh Yigit wrote:
>>>>> On 6/30/2016 6:28 PM, Thomas Monjalon wrote:
>>>>>> 2016-06-30 17:46, Jerin Jacob:
>>>>>>> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>>>>>> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>>>>>>
>>>>>> Applied, thanks
>>>>>>
>>>>>
>>>>> Hi Jerin,
>>>>>
>>>>> This commit cause a compilation error on target i686-native-linuxapp-gcc
>>>>> with gcc6.
>>>>
>>>> Besides that, I'm more curious to know have you actually seen any
>>>> performance boost?
>>>
>>> let me first address your curiosity,
>>> http://dpdk.org/dev/patchwork/patch/12993/( check the second comment)
>>> http://dpdk.org/ml/archives/dev/2016-June/042701.html
>>>
>>> Ferruh,
>>
>> Hi Jerin,
>>
>>>
>>> I have tested on a x86 machine with gcc 6.1. I could n't see any issues
>>> with i686-native-linuxapp-gcc target
>> Thanks for investigating the issue.
>>
>>>
>>> Steps following to create gcc 6.1 toolchain
>>> https://sahas.ra.naman.ms/2016/05/31/building-gcc6-1-on-fedora-23/
>>> (removed --disable-multilib to have support for -m32)
>>>
>>> ➜ [dpdk-master] $ gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=gcc
>>> COLLECT_LTO_WRAPPER=/opt/gcc-6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
>>> Target: x86_64-pc-linux-gnu
>>> Configured with: ../gcc-6.1.0/configure --prefix=/opt/gcc-6.1.0
>>> --enable-languages=c,c++ --enable-libmudflap --with-system-zlib
>>> Thread model: posix
>>> gcc version 6.1.0 (GCC)
>> I am using Fedora24, which has gcc6 (6.1.1) as default.
>>
>>>
>>> More over this issue seems like an issue from x86 rte_memcpy implementation.
>> You are right. But i686 compilation starts failing with this commit.
>> And reverting this commit in the current HEAD solves the compilation
>> problem.
>> I am not really clear about reason of the compilation error.
>
> The compile error is because compiler is so smart now and at the same
> time not enough smart.
>
> Call stack is as following:
>
> virtio_xmit_pkts_simple
> virtio_xmit_cleanup
> rte_mempool_put_bulk
> rte_mempool_generic_put
> __mempool_generic_put
> rte_memcpy
>
> The array used as source buffer in virtio_xmit_cleanup (free) is a
> pointer array with 32 elements, in 32bit this makes 128 bytes.
>
> in rte_memcpy() implementation, there a code piece as following:
> if (size > 256) {
> rte_move128(...);
> rte_move128(...); <--- [1]
> ....
> }
>
> The compiler traces the array all through the call stack and knows the
> size of array is 128 and generates a warning on above [1] which tries to
> access beyond byte 128.
> But unfortunately it ignores the "(size > 256)" check.
>
> In 64bit, this warning is not generated because array size becomes 256
> bytes.
>
> So this warning is a false positive. Although I am working on it, if
> anybody has a suggestion to prevent warning, quite welcome. At worst I
> will disable this compiler warning for the file.
I have sent a patch:
http://dpdk.org/ml/archives/dev/2016-July/043492.html
Giving a hint to compiler that variable "size" is related to the size of
the source buffer fixes compiler warning.
- This update is in virtio fast path, can you please review it from
point of performance effect.
- Isn't this surprisingly smart of compiler, or am I missing something J
Thanks,
ferruh
prev parent reply other threads:[~2016-07-07 13:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 14:50 [dpdk-dev] [PATCH] mbuf: " Jerin Jacob
2016-05-24 14:59 ` Olivier Matz
2016-05-24 15:17 ` Jerin Jacob
2016-05-27 10:24 ` Hunt, David
2016-05-27 11:42 ` Jerin Jacob
2016-05-27 15:05 ` Thomas Monjalon
2016-05-30 8:44 ` Olivier Matz
2016-05-27 13:45 ` Hunt, David
2016-06-24 15:56 ` Hunt, David
2016-06-24 16:02 ` Olivier Matz
2016-05-26 8:07 ` [dpdk-dev] [PATCH v2] mempool: " Jerin Jacob
2016-05-30 8:45 ` Olivier Matz
2016-05-31 12:58 ` Jerin Jacob
2016-05-31 21:05 ` Olivier MATZ
2016-06-01 7:00 ` Jerin Jacob
2016-06-02 7:36 ` Olivier MATZ
2016-06-02 9:39 ` Jerin Jacob
2016-06-02 21:16 ` Olivier MATZ
2016-06-03 7:02 ` Jerin Jacob
2016-06-17 10:40 ` Olivier Matz
2016-06-24 16:04 ` Olivier Matz
2016-06-30 9:41 ` Thomas Monjalon
2016-06-30 11:38 ` Jerin Jacob
2016-06-30 12:16 ` [dpdk-dev] [PATCH v3] " Jerin Jacob
2016-06-30 17:28 ` Thomas Monjalon
2016-07-05 8:43 ` Ferruh Yigit
2016-07-05 11:32 ` Yuanhan Liu
2016-07-05 13:13 ` Jerin Jacob
2016-07-05 13:42 ` Yuanhan Liu
2016-07-05 14:09 ` Ferruh Yigit
2016-07-06 16:21 ` Ferruh Yigit
2016-07-07 13:51 ` Ferruh Yigit [this message]
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=577E5E5C.2050000@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=olivier.matz@6wind.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
/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).