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: Wed, 6 Jul 2016 17:21:26 +0100 [thread overview]
Message-ID: <577D3006.1080504@intel.com> (raw)
In-Reply-To: <577BBF9F.7070503@intel.com>
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.
Thanks,
ferruh
next prev parent reply other threads:[~2016-07-06 16:21 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 [this message]
2016-07-07 13:51 ` Ferruh Yigit
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=577D3006.1080504@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).