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 0280FA0567 for ; Fri, 13 Mar 2020 08:36:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A38962BE3; 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 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: AQHV9fBz71Suucrna027AAjtXZtDbqhAAhPAgAAeKgCAACHPgIACxQ9ggAAMaNCAADvtgIAC17vw Date: Fri, 13 Mar 2020 07:36:05 +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: 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: 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-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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 the errors persist if we have the cast in dereferencing.