From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 160DBA0567;
Fri, 13 Mar 2020 08:36:22 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id E2B931C011;
Fri, 13 Mar 2020 08:36:20 +0100 (CET)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com
(mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78])
by dpdk.org (Postfix) with ESMTP id 5C5A82BE3;
Fri, 13 Mar 2020 08:36:18 +0100 (CET)
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=oEyTAwI76pUjL7Ra36DIHrwGahgAJAotrMUrF/Zh7Z0=;
b=Q4ixTyA6zmhjY+SQcyhhSWIjyGBEohSHcJxT43pdsetZrbXzRmjHmOelDAUgqC03BQ4NiGSHkD8gMdTGB1ZXR8t0zZbL0QnLPlNVRbsl5u5WgxsUeD7NlkzM2TX0B42wbzY2xzXWUfZCKV4dz1Tki2rgB97PEAaezBHsPEui3dc=
Received: from AM3PR04CA0136.eurprd04.prod.outlook.com (2603:10a6:207::20) by
VI1SPR00MB59.eurprd08.prod.outlook.com (2603:10a6:800:b0::23) with
Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2814.13; Fri, 13 Mar 2020 07:36:14 +0000
Received: from VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com
(2603:10a6:207:0:cafe::3d) by AM3PR04CA0136.outlook.office365.com
(2603:10a6:207::20) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.20 via Frontend
Transport; Fri, 13 Mar 2020 07:36:14 +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
VE1EUR03FT044.mail.protection.outlook.com (10.152.19.106) with
Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2814.13 via Frontend Transport; Fri, 13 Mar 2020 07:36:14 +0000
Received: ("Tessian outbound da94dc68d1bb:v42");
Fri, 13 Mar 2020 07:36:13 +0000
X-CR-MTA-TID: 64aa7808
Received: from 964866822ced.2
by 64aa7808-outbound-1.mta.getcheckrecipient.com id
CE0F1359-767B-494D-AD1C-67D9651747DC.1;
Fri, 13 Mar 2020 07:36:08 +0000
Received: from EUR01-VE1-obe.outbound.protection.outlook.com
by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 964866822ced.2
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
Fri, 13 Mar 2020 07:36:08 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=j/tShzP/d/JLPj7bIoOAJ5IwLE+O7LlkELKn8FCh9iFBYf99rT+HoF5dPdK096s+YeQPabceDZK0q+jqeF0IjTzhhwTp/eySgCEDKMz2szx15lKi05V/oBiezGNMxiXezo5wlFWtKliO1qXEuFCNKCzLf85805GTmBOcEDG5gFOUl3WZydXVT7+lYkuHF+2MqbYuZrTP4Csunfx+++fKJrQP5nKkgSnFgbhDkGCcg6tGJVh85wX2oQp61PhYXee2Gaa4istFSpQPQorlVUNm50tenlnB+A6S+7C8Z/0Ueuor3w+/MmJGZU/H74RqCtfGgDKaNt+Oc+qg71KEvW1JIA==
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=oEyTAwI76pUjL7Ra36DIHrwGahgAJAotrMUrF/Zh7Z0=;
b=b+FtZmLxs9k94cUl34mKyEHyCUD2ffE/Cb+z3B6WqJhlzzMJT474tTSBimHYwuvZ7Jc9XVVM2P5WUx7DlN8CThXHY2CTETspeML/a1f+sZU1GBfHAIu+RhitBxnYtISB/RV2yoP0T9Ni5bbzqTAUCeqP+GZQxqtHN82nvOnv6swBfD9LTmwPKQzpjJZQ+TNBSKFYZ57mMIuTYSjihgHJp7xF2ugn/ZJv+33OidSCDx6ThXrO54rPOrsOadBSyDDV9RKqx6dJwj9nsHZmnr+sJKgIRUNKQoeYFhTX6I5v/My+u7Iq2sNpRYY5dP2jB7YXShct/2VBlPt2lXYADu3TTg==
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=oEyTAwI76pUjL7Ra36DIHrwGahgAJAotrMUrF/Zh7Z0=;
b=Q4ixTyA6zmhjY+SQcyhhSWIjyGBEohSHcJxT43pdsetZrbXzRmjHmOelDAUgqC03BQ4NiGSHkD8gMdTGB1ZXR8t0zZbL0QnLPlNVRbsl5u5WgxsUeD7NlkzM2TX0B42wbzY2xzXWUfZCKV4dz1Tki2rgB97PEAaezBHsPEui3dc=
Received: from AM0PR08MB5363.eurprd08.prod.outlook.com (52.132.214.213) by
AM0PR08MB3092.eurprd08.prod.outlook.com (52.134.93.29) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2814.18; Fri, 13 Mar 2020 07:36:06 +0000
Received: from AM0PR08MB5363.eurprd08.prod.outlook.com
([fe80::789d:ada1:73e9:a48]) by AM0PR08MB5363.eurprd08.prod.outlook.com
([fe80::789d:ada1:73e9:a48%5]) with mapi id 15.20.2814.018; Fri, 13 Mar 2020
07:36:06 +0000
From: Gavin Hu <Gavin.Hu@arm.com>
To: 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>, "ktraynor@redhat.com"
<ktraynor@redhat.com>, "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: AQHV9fBz71Suucrna027AAjtXZtDbqhAAhPAgAAeKgCAACHPgIACxQ9ggAAMaNCAADvtgIAC17vw
Date: Fri, 13 Mar 2020 07:36:05 +0000
Message-ID: <AM0PR08MB53631F88CD719411B146EA188FFA0@AM0PR08MB5363.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>
In-Reply-To: <20200311120739.GA1922@bricha3-MOBL.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 98d63f3b-1fab-4456-98d1-db2e2825250a.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: c0a55c32-679c-4c6f-b802-08d7c72135b7
x-ms-traffictypediagnostic: AM0PR08MB3092:|AM0PR08MB3092:|VI1SPR00MB59:
x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <VI1SPR00MB5984F183A9A8CE7293F3B68FFA0@VI1SPR00MB59.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:7691;
x-forefront-prvs: 034119E4F6
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;
SFS:(10009020)(4636009)(39860400002)(346002)(376002)(366004)(136003)(396003)(199004)(6506007)(53546011)(2906002)(81166006)(8676002)(7696005)(7416002)(54906003)(55236004)(966005)(478600001)(110136005)(8936002)(66476007)(66556008)(76116006)(66446008)(81156014)(64756008)(66946007)(316002)(4326008)(186003)(71200400001)(9686003)(55016002)(86362001)(52536014)(33656002)(5660300002)(26005)(66574012);
DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3092;
H:AM0PR08MB5363.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en;
PTR:InfoNoRecords; A:1;
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: 4rGdXyRNhKzMeuRPR/4vGPadQtP1ILrvLkSYZP8eYAYPEZy2hcJ/ApBkvNByD2kN+nZrEYsEcMuiphJIkba6V0yz2cCNo358rjsjdB9XPUutDKsQjtfCC1aWCwGkXee7VU7731k0tEfdq1GcGvdpeP6U0IUNQlxqv1K/7vnMr7/WDXHc8AVPKRlftiOO1zJTZlAq8QI5fMwqS3VxdTqDZ6tIGT4jEZOU+yxTE5pLRKHH9ZdFjbRlMs8Fzns4MzYs/NMrOUxQ8ktyiJ2/DrCQqopDtq2ujIb2pbqZyuNSq7F5lgJaAW6u7PA85IFfP8VqybaQq7zxT8DbGpR/gr2yw3LnbD2s6vqJKYu041cqalfPPhXTMqYJN1bYncaKpLc9WqvJIJJwYD/dnxuF9R+lOTsyF0k8xv1tt7Gc8s1o0/MlkxB2tSzIcQEq6xNYj++XVXlPX7SiL8RAn1S1uCn/Rwzp/N7qt/8Sg3UfT23O+sxKV82jkLjkScgl8p47yTNVN6O9Aclsm3J/1pU5SMdUQA==
x-ms-exchange-antispam-messagedata: VXdtI4Lo2abMTiyL7OYnh0t/7iKP6QQwjUoXk3VYKBTsQbYfMidUBw1VGC5xjGlhu/NPOAV8aoN+vODmxL+72mgkZO4mB+sYSGxBV49JOKjob/exk1zh/n4VAF1cAhtXpmfXji80wti/SgLWhbDLMw==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3092
Original-Authentication-Results: spf=none (sender IP is )
smtp.mailfrom=Gavin.Hu@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE;
EFV:NLI; SFV:NSPM;
SFS:(10009020)(4636009)(39860400002)(396003)(136003)(346002)(376002)(199004)(46966005)(66574012)(52536014)(47076004)(7696005)(336012)(26005)(86362001)(186003)(81156014)(966005)(2906002)(478600001)(8676002)(81166006)(8936002)(26826003)(33656002)(5660300002)(450100002)(53546011)(54906003)(4326008)(110136005)(356004)(9686003)(70586007)(316002)(6506007)(36906005)(55016002)(70206006);
DIR:OUT; SFP:1101; SCL:1; SRVR:VI1SPR00MB59;
H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en;
PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 1dcdf9b9-73d0-409c-0a2f-08d7c72130c2
X-Forefront-PRVS: 034119E4F6
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: NGnON/aVoVNh6fkpkseQWR7Q0FeUbRyB3szTOHuWyNj2AV111GqVmv2fRS/1wAGLI7E5CT99/j/M2ETK2tkYuCNLqVBbTvh0ObTAeu2ZTj5sNyYVjxczrBoRAfm49OUCwK0zm3Q4yXBfIpo1CpEreP1zaHeY1YbNqtDs6CMNcCmOkpMAzhCQH6PDn1g1oYFfG27Rm9MKm+Oh7S8u4zhOcITVQ7Op9PnbxY0Ps+Da+E/+JTMHTTj2AODqmSY4RPMNnJNL8vH0cumCB7flQINPCGGN+h42Df3mqVJddViDF1E7mjXYMRKCWZSZm7cyo4uA3pMrNgt6pvypSTWPQ8J/Ljl6bUOCD5HawvjsWc+UWvoHBdDFPrBXHUWyXkCDPlIwH4eElWENefKW3S7etklL996l56WMZssDTJOu7EgI4WE1DdRrUcAMgdNSprWNjH6VLjKNcAuaEhVugQlZKMtjkWr+Pk+vmJxUUAj+iIf5qCY+B3Lme8xlFeHlWPYJDLvVCslZOmOpw2vLwEY8ovUyjMu7/ZTKXm/tdlD5ZFPRH5W9mu9kdB6tLa/w9XC2ZrWekIK15Oue1wRwfbWxyU9GjlVbgQLYYABJlZZ3UyPcFNg=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2020 07:36:14.3573 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c0a55c32-679c-4c6f-b802-08d7c72135b7
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: VI1SPR00MB59
Subject: Re: [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with
unnamed union
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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
>=20
> 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]' t=
o
> > > 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 w=
e
> > > are
> > > > > doing
> > > > > >> with them,
> > > > > >> what would you think disabling the warning instead of increasi=
ng
> > > 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, c=
an
> > > you
> > > > > please
> > > > > for more comments before changing the implementation in case ther=
e
> > > 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=3Dstric=
t-
> > > 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 origi=
nal
> suggestion) is valid C (but not C++) and is the common solution.
> >
> > Alternatives have now been discussed and tested, so we should all suppo=
rt
> your original suggestion, which seems to be the only correct and viable s=
olution.
> >
> > 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 the
> markers all together is good thinking, but it would require updating a lo=
t of
> PMDs accordingly. So please also consider removing other markers that can=
be
> removed without affecting a whole bunch of other files.
> >
>=20
> Does it still give errors if we don't have the cast in the macro?
Yes the errors persist if we have the cast in dereferencing.