From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pablo.de.lara.guarch@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id 48B4D29C6
for <dev@dpdk.org>; Mon, 4 Apr 2016 17:52:53 +0200 (CEST)
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
by fmsmga101.fm.intel.com with ESMTP; 04 Apr 2016 08:52:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,441,1455004800"; d="scan'208";a="78780870"
Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31])
by fmsmga004.fm.intel.com with ESMTP; 04 Apr 2016 08:52:03 -0700
Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by
IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Mon, 4 Apr 2016 16:51:30 +0100
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.13]) by
irsmsx111.ger.corp.intel.com ([169.254.2.127]) with mapi id 14.03.0248.002;
Mon, 4 Apr 2016 16:51:30 +0100
From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Kulasek, TomaszX"
<tomaszx.kulasek@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
Thread-Index: AQHRjoC9Ajm7Ntg020C/L3qRoeP9Ip954UAAgAAUQSA=
Date: Mon, 4 Apr 2016 15:51:30 +0000
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8973C8E7D5E@IRSMSX108.ger.corp.intel.com>
References: <1459781123-7556-1-git-send-email-tomaszx.kulasek@intel.com>
<2601191342CEEE43887BDE71AB97725836B2DF1A@irsmsx105.ger.corp.intel.com>
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B2DF1A@irsmsx105.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDkyMzA0YmQtYTkyNi00ODkxLTk2MGQtMGI4NmMxYWJhOWQ4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImMxaHZwMmJrejdzUUhUa0FVbHZ0N2habTFvT1E0cFR3dFZoNzNsYmo5NWM9In0=
x-ctpclassification: CTP_IC
x-originating-ip: [163.33.239.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2016 15:52:53 -0000
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Monday, April 04, 2016 4:35 PM
> To: Kulasek, TomaszX
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>=20
> Hi Tomasz,
>=20
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tomasz Kulasek
> > Sent: Monday, April 04, 2016 3:45 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> >
> > It seems that with gcc >5.x and -O2/-O3 optimization breaks packet
> grouping
> > algorithm.
> >
> > When last packet pointer "lp" and "pnum->u64" buffer points the same
> > memory buffer, high optimization can cause unpredictable results. It se=
ems
> > that assignment of precalculated group sizes may interfere with
> > initialization of new group size when lp points value inside current gr=
oup
> > and didn't should be changed.
> >
> > With gcc >5.x and optimization we cannot be sure which assignment will =
be
> > done first, so the group size can be counted incorrectly.
> >
> > This patch eliminates intersection of assignment of initial group size
> > (lp[0] =3D 1) and precalculated group sizes when gptbl[v].idx < 4.
> >
> > Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
> >
> > Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
> > ---
> > examples/l3fwd/l3fwd_sse.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
> > index f9cf50a..1afa1f0 100644
> > --- a/examples/l3fwd/l3fwd_sse.h
> > +++ b/examples/l3fwd/l3fwd_sse.h
> > @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t
> *lp, __m128i dp1, __m128i dp2)
> >
> > /* if dest port value has changed. */
> > if (v !=3D GRPMSK) {
> > - lp =3D pnum->u16 + gptbl[v].idx;
> > - lp[0] =3D 1;
> > pnum->u64 =3D gptbl[v].pnum;
> > + pnum->u16[FWDSTEP] =3D 1;
>=20
> Hmm, but FWDSTEP and gptbl[v].idx are not always equal.
> Actually could you explain a bit more - what exactly is reordered by gcc =
5.x,
> and how to reproduce it?
> i.e what sequence of input packets will trigger an error?
Hi Konstantin,
I could see the issue when having two flows in one port, one going to port =
0 and the other to port 1 (using Exact Match).
There is no issue when there is just one flow per port, using an older gcc =
version (< 5.0) or using O0/O1 (and of course, using LPM).
Pablo
> Konstantin
>=20
> > + lp =3D pnum->u16 + gptbl[v].idx;
> > }
> >
> > return lp;
> > --
> > 1.7.9.5