From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 125E843AA2; Sun, 18 Feb 2024 16:22:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CF8F4021D; Sun, 18 Feb 2024 16:22:30 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 76EBB400D5 for ; Sun, 18 Feb 2024 16:22:28 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8FFEA3200392; Sun, 18 Feb 2024 10:22:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 18 Feb 2024 10:22:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1708269742; x=1708356142; bh=FI8LZrmO+YZvFOxihPyUzbAjn9ZcjpcnPKCz4LRzn4c=; b= Xv8sEhqj3NKVlsFLWxne7V49wvxhspD/EuYhoZx/5RXy9pHyf6w3EN+3BZf4yzIk uElAxGqWABXsEsvsIHy8jHpeRJyvqnB5R6aoIFnISMRaoMVAq+heJStOYWbxgpIy N65OtlzC/em7LDPSkVCsg0EESexL+GD7LUyd3vAv+Yb/v23XAndn2z/HxGz0ixX/ s345NLbuoj2YXlDUwt14n1nve2DXLLMY1gSZKJuEoESTgq2217UQbnvN7Z8OFs1h QYh/BipasFi+MunczY6AJc+gSytO2jeJ1d4vby2fzLXyjZ6j6IehICjIOCUOji/7 gSUx5NNmVwXmjjo9qTDT6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1708269742; x= 1708356142; bh=FI8LZrmO+YZvFOxihPyUzbAjn9ZcjpcnPKCz4LRzn4c=; b=Z SO2FGkvv4yx1EPaqzjamgNQXed084ODCsWlqSQVvRJHAQ9JUqxie1zaO2/4MP/Xx MEi42sc/Q2FZxhYP6dp5mf4o9ODIzMSKpLjH4c0PlWClNxXdMy4DKkAcFHg200vf VOwisiIhOVeBfY5fIFuMSAB/C5BsubkCV8VvDsZxoGinexfYPtbCYijxUGbP9e4c GTJrvJKBkxx8FJ26NY971rdNfxVq/mZli8YsnuQrfwwzifMTGekUe+x/NQMG+abC LY03BGqezZwNcMAe6H9/vsOjy+NGks4UZwW43JcPZg6EHG4UBaqOtFkOMcAxknqQ bgWnEH0ucGvCe0zK/Ue7w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeigdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 18 Feb 2024 10:22:17 -0500 (EST) From: Thomas Monjalon To: dev@dpdk.org, Tyler Retzlaff , Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: Ajit Khaparde , Andrew Boyer , Andrew Rybchenko , Bruce Richardson , Chenbo Xia , Chengwen Feng , Dariusz Sosnowski , David Christensen , Hyong Youb Kim , Jerin Jacob , Jie Hai , Jingjing Wu , John Daley , Kevin Laatz , Kiran Kumar K , Konstantin Ananyev , Maciej Czekaj , Matan Azrad , Maxime Coquelin , Nithin Dabilpuram , Ori Kam , Ruifeng Wang , Satha Rao , Somnath Kotur , Suanming Mou , Sunil Kumar Kori , Viacheslav Ovsiienko , Yisen Zhuang , Yuying Zhang Subject: Re: [PATCH v4 01/18] mbuf: deprecate GCC marker in rte mbuf struct Date: Sun, 18 Feb 2024 16:22:15 +0100 Message-ID: <5265622.RUnXabflUD@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F22B@smartserver.smartshare.dk> References: <1706657173-26166-1-git-send-email-roretzla@linux.microsoft.com> <7561963.alqRGMn8q6@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9F22B@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 18/02/2024 14:07, Morten Br=F8rup: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 15/02/2024 07:21, Tyler Retzlaff: > > > --- a/lib/eal/include/rte_common.h > > > +++ b/lib/eal/include/rte_common.h > > > @@ -582,6 +582,12 @@ static void > > __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) > > > /** Marker for 8B alignment in a structure. */ > > > __extension__ typedef uint64_t RTE_MARKER64[0]; > > > > > > +#define __rte_marker(type, name) type name /* __rte_deprecated */ > > > + > > > +#else > > > + > > > +#define __rte_marker(type, name) > > > + > > > #endif > > > > > > /*********** Macros for calculating min and max **********/ > > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h > > > index 5688683..9e9590b 100644 > > > --- a/lib/mbuf/rte_mbuf_core.h > > > +++ b/lib/mbuf/rte_mbuf_core.h > > > @@ -16,7 +16,10 @@ > > > * New fields and flags should fit in the "dynamic space". > > > */ > > > > > > +#include > > > +#include > > > #include > > > +#include > > > > > > #include > > > #include > > > @@ -464,204 +467,240 @@ enum { > > > * The generic rte_mbuf, containing a packet mbuf. > > > */ > > > struct rte_mbuf { > > > - RTE_MARKER cacheline0; > > > - > > > - void *buf_addr; /**< Virtual address of segment buffer. > > */ > > > + __rte_marker(RTE_MARKER, cacheline0); > >=20 > > You don't need to keep the first argument. > > This would be simpler: > > __rte_marker(cacheline0); > > You just need to create 2 functions: __rte_marker and __rte_marker64. > >=20 > > You should replace all occurrences of RTE_MARKER in DPDK in one patch, > > and mark RTE_MARKER as deprecated (use #pragma GCC poison) >=20 > I like this suggestion. > However, some applications might use RTE_MARKER in their own structures. > Wouldn't it be considered API breakage to mark RTE_MARKER as deprecated? Yes it is an API breakage. Do we prefer waiting 24.11 for poisoning this macro?