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 AF45BA0527; Mon, 9 Nov 2020 15:42:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 11E665B30; Mon, 9 Nov 2020 15:42:35 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id D21F45AB8 for ; Mon, 9 Nov 2020 15:42:32 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7902E5801AC; Mon, 9 Nov 2020 09:42:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 09 Nov 2020 09:42:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= SxYCuJAVPP3apjNofr9n+Z9MAIPtBFDUe6zon8+Vc2g=; b=SMS8w/sPTFKqB3Wh BwAWwZah3bgHAST+zwC7BzHA766whbAch6aGIr7kDcvK7oFQv+zXmv+CBSl7ENia nCnEhuVnOrNEgvX79z7sEevwJdaXAWsqJ0iRTi3Kt8sb0EV64M6StXxU/zHfbcI7 KTgytZYQCKTRtBE7QZpnjVcORMdhL3GUtCUzCZqriTt3UePHkOSm9w/7dg6NjG5M r01N2TjtlC5W8+EKbxPSEHvLdtOcFx7PT7DCmPSz5Ny77VSf2AKGjbpEOqGRxnSK eXwJO53Pwhbx8bJbFgjTxWgmW13ziDtr2tJTAUp5w0p5U5NEWH/jyjelGCvt+ZVN N3Xj1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=SxYCuJAVPP3apjNofr9n+Z9MAIPtBFDUe6zon8+Vc 2g=; b=nyVSCxWZh6MHApttSQPaEVOyiW5qIaX3hXVmXLIL8jdma6B4wjBWMiTwZ +iWJTXn97/m9/QkJfozfGc9Xyd9/JMxCO6jlv089xZ1UN+zlw/oTraaYorB0Yzpv Fkmaikk7IJsgpJHs/zyx0Kyl7YcpH5SiWBoSD25iwnwhtpyZYYmaOZnWRyBtkXum GtN7bVlEkbiV2J0hEZZCl2EfkQ+CbQW6vNl3N5UuyvdojeWdCXRrz4Ffali+jZE5 /3S23UsJc2PGK6MB1R+riA1asW0PMlDUS96uyigIee2wSNbb/IRt+RSuiMSFL6E6 hNwZsteHJ98FFpxUQEU9ByYrzvweA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduhedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CCD20306301C; Mon, 9 Nov 2020 09:42:27 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob Cc: Bruce Richardson , dpdk-dev , David Marchand , Ferruh Yigit , Olivier Matz , Morten =?ISO-8859-1?Q?Br=F8rup?= , "Ananyev, Konstantin" , Andrew Rybchenko , Viacheslav Ovsiienko , Ajit Khaparde , Jerin Jacob , Hemant Agrawal , Ray Kinsella , Neil Horman , Nithin Dabilpuram , Kiran Kumar K , alialnu@nvidia.com, rasland@nvidia.com Date: Mon, 09 Nov 2020 15:42:26 +0100 Message-ID: <3413133.us5WgodGNe@thomas> In-Reply-To: References: <20201107155306.463148-1-thomas@monjalon.net> <2407553.B4KgyuXQMY@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/1] mbuf: move pool pointer in first half 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" 09/11/2020 15:08, Jerin Jacob: > On Mon, Nov 9, 2020 at 7:32 PM Thomas Monjalon wrote: > > 09/11/2020 14:35, Jerin Jacob: > > > Are you facing the issue with 32bit? Could you share the steps to > > > reproduce and gcc version? > > > > Oh you're right, the issue was with 32-bit build, > > Thanks > > > sorry for the confusion. > > > > > > --- a/drivers/net/octeontx2/otx2_ethdev.c > > > +++ b/drivers/net/octeontx2/otx2_ethdev.c > > > @@ -749,7 +749,7 @@ nix_tx_offload_flags(struct rte_eth_dev *eth_dev) > > > RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, pkt_len) != > > > offsetof(struct rte_mbuf, ol_flags) + 12); > > > RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, tx_offload) != > > > - offsetof(struct rte_mbuf, pool) + 2 * sizeof(void *)); > > > + offsetof(struct rte_mbuf, pool) + 2 * sizeof(uint64_t)); > > > > The actual "fix" is > > offsetof(struct rte_mbuf, pool) + sizeof(uint64_t) + sizeof(void *) > > > > I don't understand the octeontx2 vector code. > > Please check what is the impact of this offset change. > > Tested the changes, No issue seen. All the expectation of vector code > is expressed with RTE_BUILD_BUG_ON. > > > BTW, is 32-bit build really supported with octeontx2? > > No. I think, keeping assert as "sizeof(void *)"(Same as now) and remove build > support for 32bit works too for octeontx2. OK, I think it's better than tweaking RTE_BUILD_BUG_ON for something not really supported. > We will add it when really required. Then I'm going to send a patch to disable octeontx2 drivers on 32-bit. Note there is another build issue with octeontx2 drivers on CentOS/RHEL 7 with Arm GGC 4.8.