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 798DA43B58; Tue, 20 Feb 2024 20:16:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B201402A7; Tue, 20 Feb 2024 20:16:33 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 5E51C40289 for ; Tue, 20 Feb 2024 20:16:31 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EC2165C008B; Tue, 20 Feb 2024 14:16:30 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 20 Feb 2024 14:16:30 -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=1708456590; x=1708542990; bh=+FfqzLx9JIc0hieMwvvtSXsrfy6S0dCK5yQRTBjIC7A=; b= jj70u4s0IteDgdrj26q35yyeEx56op8ytDAYU35LBlWpNNIAO+KSepUQJnof4gfa sVirUV81uYYUKgjIjPIR7QUPp6hZvh+jd6cfPI/8cQrus7Bdc++M9C9Z0euy9pjg Yp8LmMIWNGTxiQWVp40Aa9KVe+3psty/nqY2eP25L1ZUrPO1ND8JgJn4Bjf0sf4a 3miV/RHQ0SaLLcTJFVuHYUuYsYaUMqst7cOVqPbvvbGDz/8wcY/pC0NZJly2cGXu 4/yFkS+fmumkefaYOlG0g9NkBOITJc0IfjFPneeJNynppKmzAVDV5UNpVrk4Aaxe /TSyG/iKhTX8dQu6FvFVBw== 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=1708456590; x= 1708542990; bh=+FfqzLx9JIc0hieMwvvtSXsrfy6S0dCK5yQRTBjIC7A=; b=g UY0WVehGIbj66ZY2mzf/znlBADwpN9NBGPhIJDzyGoKg7VPQTOci+PcLVB1DTCMP M3Ucxl7dxIL2KPcl2cH1xfzv9rebcfS3LCjxdt5VTMDfgaAHvqhP6dtgbG9h6jzW L1q8otiIex7Dg4FWk0gt70bQJ6nkE9ymjlO3/ShFrMeoDkU12sQ2Up82icis0xox zpT/sk+hO1Q1vaI4gJlWT7hjMZl4+JuAnZ7qop3QIQdcCG1Ep/NBXSYsvORlU8Lk xvVVopdu0kJFqC4BPcEd2hqhr4KkFbzrrG4jCR2HMCQXjCr0XG/gi2XEKwIcp4b/ Xdndo2R1yleeUTRw6MFVQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Feb 2024 14:16:25 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff 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 Date: Tue, 20 Feb 2024 20:16:23 +0100 Message-ID: <15805207.lVVuGzaMjS@thomas> In-Reply-To: <11059466.2WqB4rESCP@thomas> References: <1706657173-26166-1-git-send-email-roretzla@linux.microsoft.com> <20240220172023.GA14108@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <11059466.2WqB4rESCP@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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?