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 669FBA00C2; Wed, 28 Sep 2022 09:24:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 139E54113C; Wed, 28 Sep 2022 09:24:57 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id B70D141133 for ; Wed, 28 Sep 2022 09:24:55 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1DC035C016C; Wed, 28 Sep 2022 03:24:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 28 Sep 2022 03:24:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664349894; x= 1664436294; bh=MmVE/LqZ9qzfX8d7/oLO7kGvjVQtMGwCN7N+48265xw=; b=A eFh9nfxXOAeq7/I7mLwKiCIcRYgX9im0ax0gEvJE5wZUK5YUt0ON0lCa4jQKXlrk ZcQ2R4r/Y2Ter9OHHlKcqEKRb2DVb9PeKSZ3oDXRVMBEc8PZcAx9MKb28DuTZ1ky GEw89LDYL4LJa87uN9vbwbY1wzkwQ109tw09DyjYZZvin7AYkMgn/HCqgS3odXag xBCvEcy3ZWCIhgCUIb2/j/3ypUNowyO+SvcAkEvVvPdgCDIS2NzdKkOUVA9V7smH BrkQWM9dfwZb+osF137g/DWsry3PJAKbGn5x/NARFoG8l2VtcLV3ovH4FaE7Dtl6 s8K45wm4AMH35r+7Wwlxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664349894; x= 1664436294; bh=MmVE/LqZ9qzfX8d7/oLO7kGvjVQtMGwCN7N+48265xw=; b=O /Cx5lyRs32CItBcocojgxmoh5/alwBc3PNkCK/LAzEB83QN8UHf91Ym343atsnEJ yFT4wZUsdAIfipkHg9q+xfHopi7ZTLzEaoB8uWJdNO7bw7WPaF9nxK50KLluhEOF Bu19cJ3SvbON2AylgstPvZ+XRqZTEI0a30ER5y7e0mv6JJJ8K5JGhnq+K/9gXPkp UuE+31DTdPgN5cPG+j+ERAT/TqNBpicShFguGIX1N/4MvMSiD1476/UnLlrlHYlk Lnq7sgBKn8hRTT1oi/Veq8bFkbfzmxQ4NPqXxmbBCwficA/k6CEwLjjazgsSmrEV CXMUltovOBgYwZCZP01hQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegjedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 28 Sep 2022 03:24:52 -0400 (EDT) From: Thomas Monjalon To: Shijith Thotton Cc: dev@dpdk.org, pbhagavatula@marvell.com, Shijith Thotton , Honnappa.Nagarahalli@arm.com, bruce.richardson@intel.com, jerinj@marvell.com, mb@smartsharesystems.com, olivier.matz@6wind.com, stephen@networkplumber.org, david.marchand@redhat.com Subject: Re: [PATCH v3 2/5] mbuf: add second dynamic field member for VA only build Date: Wed, 28 Sep 2022 09:24:51 +0200 Message-ID: <5861713.UjTJXf6HLC@thomas> In-Reply-To: References: <20220907134340.3629224-1-sthotton@marvell.com> 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 21/09/2022 15:56, Shijith Thotton: > mbuf physical address field is not used in builds which only uses VA. It > is used to expand the dynamic field area. > > Signed-off-by: Shijith Thotton We cannot condition the use of the dynamic field. I think it is enough justification to reject this patch. And about adding a compilation option for IOVA in the first patch of this series, I think it is not the direction the majority wants DPDK to go. We tend to avoid compilation options. > @@ -579,15 +579,23 @@ struct rte_mbuf { > RTE_MARKER cacheline0; > > void *buf_addr; /**< Virtual address of segment buffer. */ > - /** > - * Physical address of segment buffer. > - * This field is invalid if the build is configured to use only > - * virtual address as IOVA (i.e. RTE_IOVA_AS_VA is 1). > - * Force alignment to 8-bytes, so as to ensure we have the exact > - * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes > - * working on vector drivers easier. > - */ > - rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t)); > + RTE_STD_C11 > + union { > + /** > + * Physical address of segment buffer. > + * This field is invalid if the build is configured to use only > + * virtual address as IOVA (i.e. RTE_IOVA_AS_VA is 1). > + * Force alignment to 8-bytes, so as to ensure we have the exact > + * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes > + * working on vector drivers easier. > + */ > + rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t)); > + /** > + * Reserved for dynamic field in builds where physical address > + * field is invalid. > + */ > + uint64_t dynfield2; > + };