From: Thomas Monjalon <thomas@monjalon.net>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, yskoh@mellanox.com, shahafs@mellanox.com,
ferruh.yigit@intel.com, bruce.richardson@intel.com,
konstantin.ananyev@intel.com, christian.ehrhardt@canonical.com,
justin.parus@microsoft.com
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: restrict workaround of gcc AVX512F bug
Date: Tue, 13 Nov 2018 01:30:26 +0100 [thread overview]
Message-ID: <3466805.ZzxQIDAxy8@xps> (raw)
In-Reply-To: <CAOaVG15R8Z76VegLpX26GpgP1GKXjzqbVPOW-wcBMvUcxNtDLg@mail.gmail.com>
13/11/2018 01:14, Stephen Hemminger:
> On Mon, Nov 12, 2018, 4:01 PM Thomas Monjalon <thomas@monjalon.net wrote:
>
> > A bug was found when the inline function mlx5_tx_complete()
> > is optimized with AVX512F instructions. It corrupts an offset
> > in the instructions vmovdqu8 of the AVX2 version of rte_mov128(),
> > used in rte_memcpy(), which is called in rte_mempool_put_bulk().
> >
> > All the above functions are inline. So the workaround is
> > to disable AVX512F optimization for the functions calling the
> > top-level function of this call stack, i.e. mlx5_tx_complete().
> > All GCC versions supporting AVX512 are supposed to be affected.
> >
> > The root cause is not identified yet. It may be thought that
> > more related bugs may happen in other functions.
> > That's why the initial workaround was to disable AVX512F globally.
> > This patch takes the risk of applying the workaround only for the
> > functions known to be affected, in order to preserve the optimization
> > everywhere else.
> >
> > Bugzilla ID: 97
> > Fixes: 8d07c82b239f ("mk: disable gcc AVX512F support")
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>
> The additional annotations clutter the code.
> How big a performance hit is it to disable for whole driver? Or just use
> memcpy instead of rte_memcpy?
rte_memcpy() is used via rte_mempool_put_bulk().
I am not going to change it to memcpy...
About disabling AVX512F for the whole driver, the goal
of this patch is to reduce the scope of the workaround.
If a per-function scope is not chosen, then we can stay with
a global safe scope.
If you are interested to know more, the bugzilla has tons of infos:
https://bugs.dpdk.org/show_bug.cgi?id=97
Given that we don't get much help on this major GCC bug,
we are probably going to stay on the safe side.
Anyway I must stop working (alone) on this bug, and instead,
focus on making 18.11 out.
next prev parent reply other threads:[~2018-11-13 0:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 0:01 Thomas Monjalon
2018-11-13 0:14 ` Stephen Hemminger
2018-11-13 0:30 ` Thomas Monjalon [this message]
2018-11-13 5:12 ` Jerin Jacob
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=3466805.ZzxQIDAxy8@xps \
--to=thomas@monjalon.net \
--cc=bruce.richardson@intel.com \
--cc=christian.ehrhardt@canonical.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=justin.parus@microsoft.com \
--cc=konstantin.ananyev@intel.com \
--cc=shahafs@mellanox.com \
--cc=stephen@networkplumber.org \
--cc=yskoh@mellanox.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).