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 57BD043B58; Tue, 20 Feb 2024 20:37:47 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D8481402A7; Tue, 20 Feb 2024 20:37:46 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 6B0FE40289 for ; Tue, 20 Feb 2024 20:37:44 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 560172083618; Tue, 20 Feb 2024 11:37:43 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 560172083618 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1708457863; bh=zFdwXnh6qh2iDtZQ5C3YURlxrlvXDEfpxugauzoFQ+I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kRs9C6hS8jjDCFD7CfFHS8kgntDf/YPVSr5WZOXu8QeqU7U+t/G4oW6/jWV2RYpif +WlRtOdDsw+lUgckW2aqrLTDnozbVu4v8jlk1GuRY8ebcMBKqszWtcbMIWQ1czxi/Y vuJ/+IpX6WspH3LUo5sAU4khTpuAJkyXRLJ3UM/g= Date: Tue, 20 Feb 2024 11:37:43 -0800 From: Tyler Retzlaff To: Thomas Monjalon Cc: dev@dpdk.org, 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 , mb@smartsharesystems.com, david.marchand@redhat.com Subject: Re: [PATCH v4 01/18] mbuf: deprecate GCC marker in rte mbuf struct Message-ID: <20240220193743.GA2728@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1706657173-26166-1-git-send-email-roretzla@linux.microsoft.com> <20240220172023.GA14108@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <11059466.2WqB4rESCP@thomas> <15805207.lVVuGzaMjS@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15805207.lVVuGzaMjS@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Tue, Feb 20, 2024 at 08:16:23PM +0100, Thomas Monjalon wrote: > 20/02/2024 18:53, Thomas Monjalon: > > 20/02/2024 18:20, Tyler Retzlaff: > > > On Sun, Feb 18, 2024 at 01:39:52PM +0100, Thomas Monjalon wrote: > > > > 15/02/2024 07:21, Tyler Retzlaff: > > > > > Provide a macro that allows conditional expansion of RTE_MARKER fields > > > > > to empty to allow rte_mbuf to be used with MSVC. It is proposed that > > > > > we announce the fields to be __rte_deprecated (currently disabled). > > > > > > > > > > Introduce C11 anonymous unions to permit aliasing of well-known > > > > > offsets by name into the rte_mbuf structure by a *new* name and to > > > > > provide padding for cache alignment. > > [...] > > > > > struct rte_mbuf { > > > > > - RTE_MARKER cacheline0; > > > > > - > > > > > - void *buf_addr; /**< Virtual address of segment buffer. */ > > > > > + __rte_marker(RTE_MARKER, cacheline0); > > > > > + union { > > > > > + char mbuf_cacheline0[RTE_CACHE_LINE_MIN_SIZE]; > > > > > + __extension__ > > > > > + struct { > > > > > + void *buf_addr; /**< Virtual address of segment buffer. > > > > > > > > I think it is ugly. > > > > > > > > Changing mbuf API is a serious issue. > > > > > > agreed, do you have an alternate proposal to solve problem? > > > > The best would be that MSVC supports a kind of struct marker. > > After more thoughts, it's OK to break API for mbuf markers. > There are 2 kind of markers in mbuf: > 1/ cacheline markers used only in rte_mbuf_prefetch_part functions > 2/ rearm_data and rx_descriptor_fields1 which are offsets used by drivers > The cacheline markers can be removed and offset calculated in prefetch functions. > The second type of markers are intended to be used by drivers only, > so there is not API compatibility concern. > Instead of complicated unions, I propose to replace them with inline functions > which return the offset in the same type as the markers. > > As RTE_MARKER macros rely on a non-standard C feature, > I propose to mark them as non-recommended, > and stop using them in DPDK code. > We can keep them for compatibility and drop them when compiling with MSVC. > > Some markers are used in crypto structures for cachelines, > we can probably drop them easily, they look unused. > > The last thing to handle is cacheline padding. > It can be done on the first field of the next cacheline, > instead of using a zero-sized marker for padding. > > Problem solved? Let's get rid of these markers? certainly simplifies things, i don't object i'll submit a new revision with the suggestions outlined above. thanks Thomas >