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 31723A0567; Fri, 13 Mar 2020 10:22:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1649D1C011; Fri, 13 Mar 2020 10:22:46 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140049.outbound.protection.outlook.com [40.107.14.49]) by dpdk.org (Postfix) with ESMTP id 5E0CA1BFFE; Fri, 13 Mar 2020 10:22:44 +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=lXYmbj6jxRo8T1MLwMV8R4a9IvgIzU5ZB8vkpoULTJc=; b=NklApSNv26U7dM2v+MVJ3mVo57zj5ZEIL3Ot90Ht+O0idO4qkxh7lT6fE//NXdL8iB2DcHa7VbuBSJlTO03Mw5ALB/3DiL8jq+6t5hZeK6IiP+haYKTfGBHAZCNgI1hMHby1DWumlgyBnozh2xQjnjRBCNWb2aESCDvfjMPQwAQ= Received: from AM6P195CA0063.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::40) by DB6PR08MB2758.eurprd08.prod.outlook.com (2603:10a6:6:1c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Fri, 13 Mar 2020 09:22:43 +0000 Received: from VE1EUR03FT028.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::92) by AM6P195CA0063.outlook.office365.com (2603:10a6:209:87::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.18 via Frontend Transport; Fri, 13 Mar 2020 09:22:43 +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 VE1EUR03FT028.mail.protection.outlook.com (10.152.18.88) 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 09:22:42 +0000 Received: ("Tessian outbound d1ceabc7047e:v42"); Fri, 13 Mar 2020 09:22:42 +0000 X-CR-MTA-TID: 64aa7808 Received: from f48e170b903b.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 13B1082C-0AE4-4E72-B0BB-CBE80A47F5DF.1; Fri, 13 Mar 2020 09:22:37 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f48e170b903b.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 13 Mar 2020 09:22:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ecaEZ+IqWLBeOviOBPOzYS/TkEG5xL1Ws792GC40LvAaOx1aApvFJT+k9ILQ1j/BQbbLXz+6TDIeS7rAtkr01qk4ztnbjLWpmnq0jc+2XrWpO+xIo7RxuH4kjQmCU3opk86zkr8gUpGTeffrzi2FBAC3YAI53AzdsocOIgCSXZgj4hw0Yj7ztYTMy7/4kwUzwIimhGcr8PcuTGK4Xhu/KO0R1bQM5AMCj0EESk8qhxH4A4bGbXphMqR+yFo4+dmnZVYa04EGnliN+b9JmIHPsOYdJ8gbmm+q1QYsOPXICjPW8+b1vzEthO8SfjcGTAInBzWlKNwMvw/OhsrzyXJUOA== 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=lXYmbj6jxRo8T1MLwMV8R4a9IvgIzU5ZB8vkpoULTJc=; b=FIHrt+ZobGesdGWeDyJlrsX22obqKHaXckR/eh8ezYv+/5EkJ1DLZ4ZZKwhORE1flipeW/6GSDNH0gCsBRrTiaOiM0DxH1tX77XrzU6/0YVXwWqKCTF8CVwwnbvKYRQP+Y1W7AxuUg2GUcp1dWjXtaTdnMuUwFEgA3v9MgpEIvLU2Ud+DYDfCyAKw3NXBzye670UWl2zIpVzz8XL9oC7p6F7Ean9Et5M0IWnxlUxww4gCjjWC+P0xDMDbEJYmEt+puLaQykOco7oW/4ivxD/NG7Wf2fc2Sv2expJiw/ZZpE0tDxI0eop8qCXTQCdAqtStSQuY4+hClj25rhb59Jbkg== 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=lXYmbj6jxRo8T1MLwMV8R4a9IvgIzU5ZB8vkpoULTJc=; b=NklApSNv26U7dM2v+MVJ3mVo57zj5ZEIL3Ot90Ht+O0idO4qkxh7lT6fE//NXdL8iB2DcHa7VbuBSJlTO03Mw5ALB/3DiL8jq+6t5hZeK6IiP+haYKTfGBHAZCNgI1hMHby1DWumlgyBnozh2xQjnjRBCNWb2aESCDvfjMPQwAQ= Received: from VI1PR08MB5376.eurprd08.prod.outlook.com (10.255.196.79) by VI1PR08MB5520.eurprd08.prod.outlook.com (52.133.246.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.16; Fri, 13 Mar 2020 09:22:33 +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.2814.018; Fri, 13 Mar 2020 09:22:33 +0000 From: Gavin Hu To: Bruce Richardson , =?iso-8859-1?Q?Morten_Br=F8rup?= CC: 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 , nd Thread-Topic: [dpdk-dev] [PATCH v2] mbuf: replace zero-length marker with unnamed union Thread-Index: AQHV9fBz71Suucrna027AAjtXZtDbqhAAhPAgAAeKgCAACHPgIACxQ9ggAAMaNCAADvtgIAC9jiw Date: Fri, 13 Mar 2020 09:22:33 +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> 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: ab33d09c-0c1a-4609-9c86-df816ca43706.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: 20f2b91b-d9e3-48ca-7b00-08d7c730157a X-MS-TrafficTypeDiagnostic: VI1PR08MB5520:|VI1PR08MB5520:|DB6PR08MB2758: 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:7691;OLM:7691; x-forefront-prvs: 034119E4F6 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(39860400002)(366004)(136003)(199004)(53546011)(55236004)(478600001)(966005)(6506007)(81166006)(55016002)(9686003)(86362001)(81156014)(33656002)(110136005)(8676002)(54906003)(7696005)(71200400001)(2906002)(76116006)(66446008)(26005)(5660300002)(186003)(66946007)(64756008)(66476007)(66574012)(8936002)(52536014)(7416002)(316002)(4326008)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB5520; H:VI1PR08MB5376.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: WZENKZF7gOi36pbfwa7k9a08aO0pZgvBOjuRubpr91p9okrDyJ91PMj3L/O9+8J5kMVIM6jE/h+cdQ11pbwsSE/uomSBJQWQiB9Wm3Un9JBxAySXjCA5R36YqOajRSL0OgZVV/HTY/4gdT+DBt2m/hCPT6gYzndfO+KK+BKz02J9ft9R0KURdTfmJ1HTb58Gt7Wxx4kkn9fYzUYwmTZ5QGbwNfnO4HLFsrleb4kIrMBIXN0qfr+v7+nSP829g5lu5j/Efjf1ZjWk+y41WjawtEtbj1WjIpDSpbocJOF+2xA/z5/MqunxaUC+l0OanR5GKjIP/QrbGrCeOe7ZoXXGvFqBAkDiviJWQpfsR//go9ENlFITUCdxRENM0ssWjWugH7pGnRqTDYarZDMS5fvWkbvvg/kvfd7AWU8RTQLj1K5zPer71RNjoqP70113/mdFab74rSc9oDdlSiQgOo7/qBNivhUiAsiZ+4tLX001DEAktVgnEsLK4pj3VDhMqz78UMb6UXVC3Nt1sKywBJZ5mA== x-ms-exchange-antispam-messagedata: ELN7NFhh49IeaBe0IieNYWrgqTQFF6kBkjHVq8QmQiBh2OVSgV/63wECcFpeMlA8sX2eltvZfwzSFg9llV6mClKAyab7peNjBw9imQR2MlgJDtqKD/xSz2K/AYtUv73n2U5g5qUwF9kn6jTIFxbo4w== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5520 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Gavin.Hu@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT028.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)(346002)(136003)(39860400002)(396003)(376002)(199004)(46966005)(55016002)(26826003)(86362001)(336012)(4326008)(2906002)(52536014)(47076004)(36906005)(9686003)(5660300002)(966005)(478600001)(356004)(81156014)(316002)(8936002)(26005)(7696005)(54906003)(70586007)(81166006)(66574012)(186003)(450100002)(70206006)(8676002)(6506007)(33656002)(53546011)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR08MB2758; 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: 0fa24598-72c1-4ca0-8863-08d7c7300fc7 X-Forefront-PRVS: 034119E4F6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2vqY9yBgLGFYfnN3ojxneKGA8/xiwuM6elmhgTDpvOsh3iLH65h3UnTRExIlu2kNChhojnrwxT8v/ciDnj3DE2UyIE29GDkW60QBTBV6i1FAAv1vsmumVeEOruMxrKx9GBaVBqW6Cy9yV/aNKG3y8e410AQqahNACZP/r1X+jawr41Ihhf6v1MgmUaO/11F8Y4+msw+nUsDA+K5t57NSqzkZALBqxsIFz7/9U6KvGMFHDtj1WOfUiZRZF/Ic0LBGNTlNoi6vuAKFGIS8Nauu4EGB6RrvfDjoqTMERsEEpfC5jfe4xEk7TdYHzwo5eVeHQ8ey8oi4QyWy7ZQe3u4cCf3e6kP0ZDdfJKc4RgdarhbBr4B6Q2TnCyUGEZMqYtPhQlnQmEku5fW4+O2wl9zBaD3FvYsRPM1f2AVhlEyfhsDkWf9/+vtnJga4bxAuoZp1nKUw+pi6YfQG2AaLydQu+rnIOZz25+DDA7rjLq+Yqn9PYmuAwMeJm6cV6SnxDXMSI0+2mVL4i0pnfW/q1wD4z1WjSbOnjENop/u2kARVsW7+3wOkID6oWK5ROBpEjlQbeH8aUWQAw5Dz1sZWRIO5hdb7fizgSLsjWVjaAhiXwlo= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2020 09:22:42.6908 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 20f2b91b-d9e3-48ca-7b00-08d7c730157a 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: DB6PR08MB2758 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 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 >=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 > > > > 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]' t= o > > > 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 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, it gives errors elsewhere that have the cast.=20