DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>
Cc: <dev@dpdk.org>, Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Subject: Re: [RFC] eal/x86: disable array bounds checks in rte_memcpy_generic with gcc-12
Date: Fri, 10 Jun 2022 13:06:25 +0100	[thread overview]
Message-ID: <005540f3-71a4-d45d-01fb-46a682c70d94@xilinx.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8710F@smartserver.smartshare.dk>

On 6/10/2022 11:39 AM, Morten Brørup wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
> 
> 
>> From: Ferruh Yigit [mailto:ferruh.yigit@xilinx.com]
>> Sent: Friday, 10 June 2022 12.13
>>
>> On 6/8/2022 11:49 PM, Stephen Hemminger wrote:
>>> Gcc 12 adds more array bounds checking (good); but it is not smart
>>> enough to realize that for small fixed sizes, the bigger move options
>>> are not used.
>>>
>>> An example is using rte_memcpy() on a RSS key of 40 bytes may trigger
>>> rte_memcpy complaints from rte_mov128 reading past end of input.
>>>
>>> In order to keep some of the checks add special case for calls
>>> to rte_memcpy() with fixed size arguments to use the compiler
>>> builtin instead. Don't want to give all the checking for
>>> code that uses rte_memcpy() everywhere.
>>>
>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>> ---
>>>    lib/eal/x86/include/rte_memcpy.h | 16 +++++++++++-----
>>>    1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/lib/eal/x86/include/rte_memcpy.h
>> b/lib/eal/x86/include/rte_memcpy.h
>>> index 18aa4e43a743..b90cdd8d7326 100644
>>> --- a/lib/eal/x86/include/rte_memcpy.h
>>> +++ b/lib/eal/x86/include/rte_memcpy.h
>>> @@ -27,6 +27,10 @@ extern "C" {
>>>    #pragma GCC diagnostic ignored "-Wstringop-overflow"
>>>    #endif
>>>
>>> +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 120000)
>>> +#pragma GCC diagnostic ignored "-Warray-bounds"
>>> +#endif
>>> +
>>>    /**
>>>     * Copy bytes from one location to another. The locations must not
>> overlap.
>>>     *
>>> @@ -842,19 +846,21 @@ rte_memcpy_aligned(void *dst, const void *src,
>> size_t n)
>>>      return ret;
>>>    }
>>>
>>> +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 100000)
>>> +#pragma GCC diagnostic pop
>>> +#endif
>>> +
>>>    static __rte_always_inline void *
>>>    rte_memcpy(void *dst, const void *src, size_t n)
>>>    {
>>> -   if (!(((uintptr_t)dst | (uintptr_t)src) & ALIGNMENT_MASK))
>>> +   if (__builtin_constant_p(n))
>>> +           return __builtin_memcpy(dst, src, n);
>>> +   else if (!(((uintptr_t)dst | (uintptr_t)src) & ALIGNMENT_MASK))
>>
>> This patch does two things,
>>
>> 1. Disable "-Warray-bounds" with above pragma to silence compiler
>> warnings.
>>
>> 2. Use compiler builtin for some cases.
>>
>> Second can impact the performance and not really needed for the build
>> error, what do you think to split the patch in two, since 1. is simple
>> change but 2. may require more testing before accepting.
> 
> Any such testing will be highly compiler dependent.
> 
> Do you have any specific compilers in mind, where you see a risk for lower performance?
> 

Hi Morten,

My point is possible performance impact, not about any possible risk or 
specific compiler version.
The possible performance impact part can be separated to its own patch 
and these can be discussed there, independent from gcc12 build error.

      reply	other threads:[~2022-06-10 12:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 22:49 Stephen Hemminger
2022-06-09  7:26 ` Morten Brørup
2022-06-10  0:08 ` Konstantin Ananyev
2022-06-10 10:12 ` Ferruh Yigit
2022-06-10 10:39   ` Morten Brørup
2022-06-10 12:06     ` 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=005540f3-71a4-d45d-01fb-46a682c70d94@xilinx.com \
    --to=ferruh.yigit@xilinx.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=mb@smartsharesystems.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).