From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C4148A0597; Wed, 8 Apr 2020 17:04:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A70D51C198; Wed, 8 Apr 2020 17:04:39 +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 To: Kevin Traynor , Bruce Richardson , =?iso-8859-1?Q?Morten_Br=F8rup?= CC: Ferruh Yigit , "dev@dpdk.org" , nd , "david.marchand@redhat.com" , "thomas@monjalon.net" , "jerinj@marvell.com" , Honnappa Nagarahalli , Ruifeng Wang , Phil Yang , Joyce Kong , "stable@dpdk.org" , Olivier MATZ , Konstantin Ananyev , Andrew Rybchenko , nd 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: References: <20200303162728.93744-1-gavin.hu@arm.com> <20200307155629.45021-1-gavin.hu@arm.com> <4135ab73-75d3-421a-264d-2951fc096133@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C60EA3@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C60EAC@smartserver.smartshare.dk> <20200311120739.GA1922@bricha3-MOBL.ger.corp.intel.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: 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-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Kevin,=20 > -----Original Message----- > From: Kevin Traynor > Sent: Wednesday, April 8, 2020 1:14 AM > To: Gavin Hu ; Bruce Richardson > ; Morten Br=F8rup > > Cc: Ferruh Yigit ; dev@dpdk.org; nd > ; david.marchand@redhat.com; thomas@monjalon.net; > jerinj@marvell.com; Honnappa Nagarahalli > ; Ruifeng Wang > ; Phil Yang ; Joyce Kong > ; stable@dpdk.org; Olivier MATZ > ; Konstantin Ananyev > ; Andrew Rybchenko > > 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 > >> Sent: Wednesday, March 11, 2020 8:08 PM > >> To: Morten Br=F8rup > >> Cc: Gavin Hu ; Ferruh Yigit > ; > >> dev@dpdk.org; nd ; david.marchand@redhat.com; > >> thomas@monjalon.net; ktraynor@redhat.com; jerinj@marvell.com; > >> Honnappa Nagarahalli ; Ruifeng > Wang > >> ; Phil Yang ; Joyce Kong > >> ; stable@dpdk.org; Olivier MATZ > >> ; Konstantin Ananyev > >> ; Andrew Rybchenko > >> > >> 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 > >>>>> 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 > >>>>>>>> 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 > >>>>>>>>> --- > >>>>>>>>> v2: > >>>>>>>>> * change 'uint64_t rearm_data' to 'uint_64_t rearm_data[1]' to > >>>> fix > >>>>>>>>> the SFC PMD compiling error on x86. > >>>>>>>>> --- > >>>>>>>>> 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