From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 162C0A0598
for <public@inbox.dpdk.org>; Wed, 8 Apr 2020 17:04:41 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id EE7EE1C1D7;
Wed, 8 Apr 2020 17:04:40 +0200 (CEST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com
(mail-eopbgr40074.outbound.protection.outlook.com [40.107.4.74])
by dpdk.org (Postfix) with ESMTP id C4C6E1C194;
Wed, 8 Apr 2020 17:04:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
s=selector2-armh-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=K1L2YkmPIeL/dSWPLkrIInaQsztkKaLWZR+5/OOftOM=;
b=SsXon5peuzozw1oWPtfC4udVFhNyXvC9aRsdLYEzVbPQPqMK1/yKeIUI4rXBBPYdNbxTpQ/yNVGi//CzW1jhpLFmaxhkZ6fvxuhjEJiSyw6/bw5j6VsMKaffP2uCLg9F6vcJXpk5Lfyz3tF3SbxzOQCBcQv7gIMIqUlriBHnz4Y=
Received: from AM6P194CA0031.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:90::44)
by AM5PR0801MB2049.eurprd08.prod.outlook.com (2603:10a6:203:42::12) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Wed, 8 Apr
2020 15:04:36 +0000
Received: from VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com
(2603:10a6:209:90:cafe::1) by AM6P194CA0031.outlook.office365.com
(2603:10a6:209:90::44) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend
Transport; Wed, 8 Apr 2020 15:04:36 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123)
smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified)
header.d=armh.onmicrosoft.com;dpdk.org; dmarc=bestguesspass action=none
header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
63.35.35.123 as permitted sender) receiver=protection.outlook.com;
client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
VE1EUR03FT045.mail.protection.outlook.com (10.152.19.51) with
Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2856.17 via Frontend Transport; Wed, 8 Apr 2020 15:04:35 +0000
Received: ("Tessian outbound 55454527ea3b:v50");
Wed, 08 Apr 2020 15:04:34 +0000
X-CR-MTA-TID: 64aa7808
Received: from 0713f46708ff.2
by 64aa7808-outbound-1.mta.getcheckrecipient.com id
7C08B633-C133-40F6-A601-E1B9DF1108D7.1;
Wed, 08 Apr 2020 15:04:29 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0713f46708ff.2
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
Wed, 08 Apr 2020 15:04:29 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=kRhUQ5pbwu04FhVvUUia47hIyYEnpZKefLvLMlFFja1Rd/W/VYPxgU9POm4v2ZO8ug0fv2yqHVivLrITlSNzl894Rjo9DBSnXJwN6+EV2hzvpVeXQiwNd61H/4ph4dxv481iPshbyrfhvrXYuIHYxKxMZu5zur+uRmJYBhPIOyN++pTfc/BeXmzG5e6+nGhruMgI+BksuA+QOI2E4evDIsArY5Kf8M0T/h2WKnkPpqJP4nds3QBNDy7I2LJGSuxQVhhdmup8xSq+jSuHqs3PDp10oNAyuHNWh+33l5hpPO/+tEp4AP5zIKYkIoNu/pQ2tYbEMXQ9lmq+/NfuPYTF+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=K1L2YkmPIeL/dSWPLkrIInaQsztkKaLWZR+5/OOftOM=;
b=Bdv7zI71IdyIXHdMKfrWelb7CcfavMrGtoZ60t87V2Gf8PT2HipeqxiwhAHLr7GytzQL3t/xuUkJ21i3fC9b7NT9XqVyOWjMjYsMjLlwYOVh+hpXkWCJD62yLUPbd9k9jyIwSKZgArdxlB+PtWlMiaD+g3DmtI5VfDh6mVzOzFpjk9ekA0mZHX9/t1PtFU+1puaxhGj9GaBr/12izkzKbIwX2Jya/8PUkGJFJfaBcaUMjWl1S3mbwrWxYHwck2LrP/6UuMSFv/WAwPQ7mjHhmEnEmykZUJd3R5Pu++ChC1/alYxDbBkfEpbNi3u5UUL+H/0QBx0t5lvKIOBGXxLOSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
s=selector2-armh-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=K1L2YkmPIeL/dSWPLkrIInaQsztkKaLWZR+5/OOftOM=;
b=SsXon5peuzozw1oWPtfC4udVFhNyXvC9aRsdLYEzVbPQPqMK1/yKeIUI4rXBBPYdNbxTpQ/yNVGi//CzW1jhpLFmaxhkZ6fvxuhjEJiSyw6/bw5j6VsMKaffP2uCLg9F6vcJXpk5Lfyz3tF3SbxzOQCBcQv7gIMIqUlriBHnz4Y=
Received: from VI1PR08MB5376.eurprd08.prod.outlook.com (2603:10a6:803:13e::15)
by VI1PR08MB4607.eurprd08.prod.outlook.com (2603:10a6:803:bf::30)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr
2020 15:04:26 +0000
Received: from VI1PR08MB5376.eurprd08.prod.outlook.com
([fe80::a0e2:2a9f:be7b:4b15]) by VI1PR08MB5376.eurprd08.prod.outlook.com
([fe80::a0e2:2a9f:be7b:4b15%3]) with mapi id 15.20.2900.015; Wed, 8 Apr 2020
15:04:26 +0000
From: Gavin Hu <Gavin.Hu@arm.com>
To: Kevin Traynor <ktraynor@redhat.com>, Bruce Richardson
<bruce.richardson@intel.com>, =?iso-8859-1?Q?Morten_Br=F8rup?=
<mb@smartsharesystems.com>
CC: Ferruh Yigit <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, nd
<nd@arm.com>, "david.marchand@redhat.com" <david.marchand@redhat.com>,
"thomas@monjalon.net" <thomas@monjalon.net>, "jerinj@marvell.com"
<jerinj@marvell.com>, Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Ruifeng Wang <Ruifeng.Wang@arm.com>, Phil Yang <Phil.Yang@arm.com>, Joyce
Kong <Joyce.Kong@arm.com>, "stable@dpdk.org" <stable@dpdk.org>, Olivier MATZ
<olivier.matz@6wind.com>, Konstantin Ananyev <konstantin.ananyev@intel.com>,
Andrew Rybchenko <arybchenko@solarflare.com>, nd <nd@arm.com>
Thread-Topic: [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with
unnamed union
Thread-Index: AQHV9fBz71Suucrna027AAjtXZtDbqhAAhPAgAAeKgCAACHPgIACxQ9ggAAMaNCAADvtgIAC9jiwgCfON4CAAVzWkA==
Date: Wed, 8 Apr 2020 15:04:24 +0000
Message-ID: <VI1PR08MB53763BF05826A780F949C2018FC00@VI1PR08MB5376.eurprd08.prod.outlook.com>
References: <20200303162728.93744-1-gavin.hu@arm.com>
<20200307155629.45021-1-gavin.hu@arm.com>
<4135ab73-75d3-421a-264d-2951fc096133@intel.com>
<VI1PR08MB53761D519B18A133E05F082A8FFE0@VI1PR08MB5376.eurprd08.prod.outlook.com>
<dffb4554-4719-8838-3001-eebdf7228c48@intel.com>
<98CBD80474FA8B44BF855DF32C47DC35C60EA3@smartserver.smartshare.dk>
<VI1PR08MB5376761A8FD748CA357472C78FFC0@VI1PR08MB5376.eurprd08.prod.outlook.com>
<98CBD80474FA8B44BF855DF32C47DC35C60EAC@smartserver.smartshare.dk>
<20200311120739.GA1922@bricha3-MOBL.ger.corp.intel.com>
<VI1PR08MB537656561D1E1614CD9B01428FFA0@VI1PR08MB5376.eurprd08.prod.outlook.com>
<30507744-63d4-c24b-4cc3-de7adff871f6@redhat.com>
In-Reply-To: <30507744-63d4-c24b-4cc3-de7adff871f6@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 5fa73627-1414-4dda-b0e7-5a837af84077.0
x-checkrecipientchecked: true
Authentication-Results-Original: spf=none (sender IP is )
smtp.mailfrom=Gavin.Hu@arm.com;
x-originating-ip: [113.29.88.7]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 222a7a85-127a-45c5-475f-08d7dbce26ad
x-ms-traffictypediagnostic: VI1PR08MB4607:|VI1PR08MB4607:|AM5PR0801MB2049:
x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <AM5PR0801MB204986F8C6B2E5BC15B2EB818FC00@AM5PR0801MB2049.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882;
x-forefront-prvs: 0367A50BB1
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en;
SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB5376.eurprd08.prod.outlook.com;
PTR:; CAT:NONE; SFTY:;
SFS:(10009020)(4636009)(376002)(366004)(39860400002)(346002)(396003)(136003)(110136005)(71200400001)(86362001)(7416002)(8936002)(7696005)(8676002)(9686003)(81156014)(54906003)(55236004)(55016002)(66574012)(53546011)(6506007)(66556008)(64756008)(66446008)(316002)(478600001)(2906002)(186003)(966005)(52536014)(26005)(81166007)(5660300002)(76116006)(66946007)(66476007)(4326008)(33656002);
DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: arm.com does not designate
permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: e5Vgr8uXTnFMRbTB65sN4N7BwtDlJg2FfU7uHWwnDfprRj0reqOsvNS4brGoEZRAqt4tElSrkLBNK334bLjqPRibxAwia1A7Kfjb+FXwdznCQUK74ZJ46ymF4RQbfTX3HNXMgAvhhHfWtA6V6XyVFSqP+lR/VuwJ//YS2S0keoNo7qmtuKcwnF5BWKEGHcAiRUtjnwmzgUGe49e91yLI8PpzQgNZtE80Pmq0lLPO2CSek0PSzOZ70ptkHaS8UP61/aDj8pfalfLHSzeQkRQYOlHwWTjYT0bzpn8r7ytCF3FkNBtC7ThCa4bFQlHHxakCEovu8xfC7Z5T2dywPx0RTbDxBkQB3t+IUP0xU1+RRdwuXaQmp57XeRGbTGtrIBQQy3T/v4N9aqZIZvU+Oycr1SxDCTIEnC1L8lGWyVdvrcncbt64qH82lLV2Sciw2PlyoLsa46nYWBShxC9x62IQndAoXKNqsyvfsDucByYeeJhgiPZ/fOtS7BgV9a3O5bcc4jsH+PEPLdiSq5+bQHF/jg==
x-ms-exchange-antispam-messagedata: 1gHWvJlCiNuZgMKO+7hqaNfwPlDAFzLxpc2RmzQFiX2NZA4qjuQyNcOvcjbMuJrkMuZsd9/n0WEOguJ5+mduvp+yQspMpzMGzGIiPzOvb3rldmSmSAczMXGPdwTvHUp/S6Z4gDCkEf7OFdEt0baz0A==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4607
Original-Authentication-Results: spf=none (sender IP is )
smtp.mailfrom=Gavin.Hu@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;
IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;
PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;
SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(39860400002)(46966005)(54906003)(186003)(356004)(8936002)(6506007)(86362001)(47076004)(81166007)(53546011)(4326008)(8676002)(82740400003)(26005)(7696005)(478600001)(9686003)(66574012)(336012)(966005)(5660300002)(26826003)(2906002)(36906005)(70206006)(316002)(81156014)(52536014)(55016002)(110136005)(33656002)(450100002)(70586007);
DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 874396f7-545f-4d16-cbf8-08d7dbce211a
X-Forefront-PRVS: 0367A50BB1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: HvIy0tsn4DOWmhQ1rdUT6HHcrpK382G6rD85f+0Yi5NgSr83CCsGIJVJMqG7Jpn/WW/ojs9yZ+BOnJuPlHNSpRr7UuaTwdC7Za37flReCLY0toSu0z1KtsaNyueilCecdbC21tmaQ0AModbNmIkPuSeClBxjM0Pfv9MDU2ZG7feygM6Y5slYWYeiAf/lKMc4ICQ1EZ4y22qUlVDXMifgLkkBXdOyOBurGSJbJ/hqOA7oyCjs06Q5vd3SWs1LcbMb1Qe95NeCYIpvZQhpyB83j7HLg9eZ05EPVdR/jC9hw6J1oZGLKlQjOF5SMRiEUn9tJYkMyhzfrxhor0b2sGHn19aHkJJ8fVdlA6uO3k0+mNRbPJ3+Z2VFDPPel4wzRZNeQuzCg6Mzg9K58UTW2Eim/5td/0mUW1iwmb/rFEUdT2YMsCbM8dbAbAjEbQpAXFK5fZIvsLXkAFezldieW194Y84CBv8PdRH93Ge4hDkVcWzU9lM0SBkZYIM4zcF2LANKcOQmv7gBWgJq9zNYUyL14CB/C76123H48MI49YwOFIs0X/rrGX1vEaotyX8hJZ3Dk+ZqLhaWzf/WLGxKUn8y5JUQGtQkIg4ZMLvWrLiomWk=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 15:04:35.3189 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 222a7a85-127a-45c5-475f-08d7dbce26ad
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];
Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB2049
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] mbuf: replace zero-length
marker with unnamed union
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
Hi Kevin,=20
> -----Original Message-----
> From: Kevin Traynor <ktraynor@redhat.com>
> Sent: Wednesday, April 8, 2020 1:14 AM
> To: Gavin Hu <Gavin.Hu@arm.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Morten Br=F8rup
> <mb@smartsharesystems.com>
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; dev@dpdk.org; nd
> <nd@arm.com>; david.marchand@redhat.com; thomas@monjalon.net;
> jerinj@marvell.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; Ruifeng Wang
> <Ruifeng.Wang@arm.com>; Phil Yang <Phil.Yang@arm.com>; Joyce Kong
> <Joyce.Kong@arm.com>; stable@dpdk.org; Olivier MATZ
> <olivier.matz@6wind.com>; Konstantin Ananyev
> <konstantin.ananyev@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Subject: Re: [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with
> unnamed union
>=20
> On 13/03/2020 09:22, Gavin Hu wrote:
> > Hi Bruce,
> >
> >> -----Original Message-----
> >> From: Bruce Richardson <bruce.richardson@intel.com>
> >> Sent: Wednesday, March 11, 2020 8:08 PM
> >> To: Morten Br=F8rup <mb@smartsharesystems.com>
> >> Cc: Gavin Hu <Gavin.Hu@arm.com>; Ferruh Yigit
> <ferruh.yigit@intel.com>;
> >> dev@dpdk.org; nd <nd@arm.com>; david.marchand@redhat.com;
> >> thomas@monjalon.net; ktraynor@redhat.com; jerinj@marvell.com;
> >> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Ruifeng
> Wang
> >> <Ruifeng.Wang@arm.com>; Phil Yang <Phil.Yang@arm.com>; Joyce Kong
> >> <Joyce.Kong@arm.com>; stable@dpdk.org; Olivier MATZ
> >> <olivier.matz@6wind.com>; Konstantin Ananyev
> >> <konstantin.ananyev@intel.com>; Andrew Rybchenko
> >> <arybchenko@solarflare.com>
> >> Subject: Re: [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker
> with
> >> unnamed union
> >>
> >> On Wed, Mar 11, 2020 at 10:04:33AM +0100, Morten Br=F8rup wrote:
> >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Gavin Hu
> >>>> Sent: Wednesday, March 11, 2020 8:50 AM
> >>>>
> >>>> Hi Morten,
> >>>>
> >>>>> From: Morten Br=F8rup <mb@smartsharesystems.com>
> >>>>> Sent: Monday, March 9, 2020 9:31 PM
> >>>>>
> >>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> >>>>>> Sent: Monday, March 9, 2020 12:30 PM
> >>>>>>
> >>>>>> On 3/9/2020 9:45 AM, Gavin Hu wrote:
> >>>>>>> Hi Ferruh,
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>>>>>>> Sent: Monday, March 9, 2020 4:55 PM
> >>>>>>>>
> >>>>>>>> On 3/7/2020 3:56 PM, Gavin Hu wrote:
> >>>>>>>>> Declaring zero-length arrays in other contexts, including as
> >>>>>> interior
> >>>>>>>>> members of structure objects or as non-member objects, is
> >>>>>> discouraged.
> >>>>>>>>> Accessing elements of zero-length arrays declared in such
> >>>> contexts
> >>>>>> is
> >>>>>>>>> undefined and may be diagnosed.[1]
> >>>>>>>>>
> >>>>>>>>> Fix by using unnamed union and struct.
> >>>>>>>>>
> >>>>>>>>> https://bugs.dpdk.org/show_bug.cgi?id=3D396
> >>>>>>>>>
> >>>>>>>>> Bugzilla ID: 396
> >>>>>>>>>
> >>>>>>>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> >>>>>>>>>
> >>>>>>>>> Fixes: 3e6181b07038 ("mbuf: use structure marker from EAL")
> >>>>>>>>> Cc: stable@dpdk.org
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> >>>>>>>>> ---
> >>>>>>>>> v2:
> >>>>>>>>> * change 'uint64_t rearm_data' to 'uint_64_t rearm_data[1]' to
> >>>> fix
> >>>>>>>>> the SFC PMD compiling error on x86. <Kevin Traynor>
> >>>>>>>>> ---
> >>>>>>>>> lib/librte_mbuf/rte_mbuf_core.h | 54 +++++++++++++++++++----
> >> --
> >>>> ----
> >>>>>> ----
> >>>>>>>>> 1 file changed, 32 insertions(+), 22 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/lib/librte_mbuf/rte_mbuf_core.h
> >>>>>>>> b/lib/librte_mbuf/rte_mbuf_core.h
> >>>>>>>>> index b9a59c879..34cb152e2 100644
> >>>>>>>>> --- a/lib/librte_mbuf/rte_mbuf_core.h
> >>>>>>>>> +++ b/lib/librte_mbuf/rte_mbuf_core.h
> >>>>>>>>> @@ -480,31 +480,41 @@ struct rte_mbuf {
> >>>>>>>>> rte_iova_t buf_physaddr; /**< deprecated */
> >>>>>>>>> } __rte_aligned(sizeof(rte_iova_t));
> >>>>>>>>>
> >>>>>>>>> - /* next 8 bytes are initialised on RX descriptor rearm */
> >>>>>>>>> - RTE_MARKER64 rearm_data;
> >>>>>>>>> - uint16_t data_off;
> >>>>>>>>> -
> >>>>>>>>> - /**
> >>>>>>>>> - * Reference counter. Its size should at least equal to the
> >>>> size
> >>>>>>>>> - * of port field (16 bits), to support zero-copy broadcast.
> >>>>>>>>> - * It should only be accessed using the following
> >>>> functions:
> >>>>>>>>> - * rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> >>>>>>>>> - * rte_mbuf_refcnt_set(). The functionality of these
> >>>> functions
> >>>>>> (atomic,
> >>>>>>>>> - * or non-atomic) is controlled by the
> >>>>>>>> CONFIG_RTE_MBUF_REFCNT_ATOMIC
> >>>>>>>>> - * config option.
> >>>>>>>>> - */
> >>>>>>>>> RTE_STD_C11
> >>>>>>>>> union {
> >>>>>>>>> - rte_atomic16_t refcnt_atomic; /**< Atomically
> >>>> accessed
> >>>>>>>> refcnt */
> >>>>>>>>> - /** Non-atomically accessed refcnt */
> >>>>>>>>> - uint16_t refcnt;
> >>>>>>>>> - };
> >>>>>>>>> - uint16_t nb_segs; /**< Number of segments. */
> >>>>>>>>> + /* next 8 bytes are initialised on RX descriptor
> >>>> rearm */
> >>>>>>>>> + uint64_t rearm_data[1];
> >>>>>>>> We are using zero length array as markers only and know what
> we
> >>>> are
> >>>>>> doing
> >>>>>>>> with them,
> >>>>>>>> what would you think disabling the warning instead of increasing
> >>>> the
> >>>>>>>> complexity
> >>>>>>>> in mbuf struct?
> >>>>>>> Okay, I will add -Wno-zero-length-bounds to the compiler
> >>>> toolchain
> >>>>>> flags.
> >>>>>>
> >>>>>> This would be my preference but I would like to get more input, ca=
n
> >>>> you
> >>>>>> please
> >>>>>> for more comments before changing the implementation in case
> there
> >>>> are
> >>>>>> some
> >>>>>> strong opinion on it?
> >>>>>>
> >>>>>
> >>>>> I have some input to this discussion.
> >>>>>
> >>>>> Let me repeat what Gavin's GCC reference states: Declaring zero-
> >>>> length
> >>>>> arrays [...] as interior members of structure objects [...] is
> >>>> discouraged.
> >>>>>
> >>>>> Why would we do something that the compiler documentation says is
> >>>>> discouraged? I think the problem (i.e. using discouraged techniques=
)
> >>>> should
> >>>>> be fixed, not the symptom (i.e. getting warnings about using
> >>>> discouraged
> >>>>> techniques).
> >>>>>
> >>>>> Compiler warnings are here to help, and in my experience they are
> >>>> actually
> >>>>> very helpful, although avoiding them often requires somewhat more
> >>>>> verbose source code. Disabling this warning not only affects this
> >>>> file, but
> >>>>> disables warnings about potential bugs in other source code too.
> >>>>>
> >>>>> Generally, disabling compiler warnings is a slippery slope. It woul=
d
> >>>> be
> >>>>> optimal if DPDK could be compiled with -Wall, and it would probably
> >>>> reduce
> >>>>> the number of released bugs too.
> >>>>>
> >>>>> With that said, sometimes the optimal solution has to give way for
> >>>> the
> >>>>> practical solution. And this is a core file, so we should thread
> >>>> lightly.
> >>>>>
> >>>>>
> >>>>> As for an alternative solution, perhaps we can get rid of the MARKE=
Rs
> >>>> in the
> >>>>> struct and #define them instead. Not as elegant as Gavin's suggeste=
d
> >>>> union
> >>>>> based solution, but it might bring inspiration...
> >>>>>
> >>>>> struct rte_mbuf {
> >>>>> ...
> >>>>> } __rte_aligned(sizeof(rte_iova_t));
> >>>>>
> >>>>> uint16_t data_off;
> >>>>> ...
> >>>>> }
> >>>>>
> >>>>> #define rte_mbuf_rearm_data(m) ((uint64_t *)m->data_off)
> >>>>
> >>>> This does not work out, it generates new errors:
> >>>> /root/dpdk/build/include/rte_mbuf_core.h:485:33: error:
> dereferencing
> >>>> type-punned pointer will break strict-aliasing rules [-Werror=3Dstri=
ct-
> >>>> aliasing]
> >>>> 485 | #define rte_mbuf_rearm_data(m) ((uint64_t *)&m->data_off)
> >>>>
> >>>
> >>> OK. Then Bruce's suggestion probably won't work either.
> >>>
> >>> I found this article about strict aliasing:
> >> https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8
> >>>
> >>> The article basically says that the union based method (i.e. your ori=
ginal
> >> suggestion) is valid C (but not C++) and is the common solution.
> >>>
> >>> Alternatives have now been discussed and tested, so we should all
> support
> >> your original suggestion, which seems to be the only correct and viabl=
e
> solution.
> >>>
> >>> Please go ahead with that, and then someone should update the SFC
> PMD
> >> accordingly.
> >>>
> >>> Furthermore, I think that Stephen's suggestion about getting rid of t=
he
> >> markers all together is good thinking, but it would require updating a=
lot
> of
> >> PMDs accordingly. So please also consider removing other markers that
> can be
> >> removed without affecting a whole bunch of other files.
> >>>
> >>
> >> Does it still give errors if we don't have the cast in the macro?
> >
> > Yes, it gives errors elsewhere that have the cast.
> >
>=20
> Hi Gavin, I lost track if v2 is still a candidate for merge. fwiw, it
> compiles without giving the zero-length-bounds warning on my system.
>=20
> Kevin.
Yes, this path alone is a candidate for merge.=20
We brainstormed other solutions but they did not work out.=20
/Gavin