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 79B81A00C4; Wed, 28 Sep 2022 21:34:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25CCE4113C; Wed, 28 Sep 2022 21:34:01 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 6F9BA410FA for ; Wed, 28 Sep 2022 21:33:59 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C105A5C003E; Wed, 28 Sep 2022 15:33:58 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 28 Sep 2022 15:33:58 -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=1664393638; x= 1664480038; bh=tg0n5NDHAmkLfP9BW27LbaUYEzKxfkqOHtHE876bmcI=; b=A oLTAPOrJ/39jOomeUi21pdiUABpTI7r7ga0hJMnt/d+nRkNu30h9/MIpIHOhm73i kvvb3f/lYdge9NX8mqswhydjdyUfC4XTIEnWDvgOC++qJSxMKS8qRMscE7yOehm2 JjI374MDuUr+VW0ylZ7FqR1ykGbNDpB54lhd+qkWXlD2B0qWNjnBpt8Bn70hmB7N YfTNpRP+oy8umRgFnQIY/SJ4Yv3tfBXOMi4Ig74RdCEHOtBIql/W3eLXfPiv6rCW 4OVp75CD07ynZDM60QJcnPCwhk4Wj+xDiI3IJOMNczv5wxQ7uR/xSk9xj1pLNW5C x4PO2MgKE8LzjRQKmemFw== 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=1664393638; x= 1664480038; bh=tg0n5NDHAmkLfP9BW27LbaUYEzKxfkqOHtHE876bmcI=; b=l z4/J0St6Yzzf3Utlls5kkCeAP8oChdDyTjnPlgUR06g3uVxmcJLj/6/KGbpUsX9s 7DhIEkks9G0WvcuFTL/ho4FdIC1kTir7/4OgEQvoYgZcm++UzPvpdaC9MBuaSLHE LSpNKyRATqU47fhP9Nz3o35WTSu3VePwIMGhCQNNRWq/dzGw9Nhscym+JtJU9eUk ilvbd2a2DjlqJ9SrIVN3OfSzf/LZ2gN9I0+ioHFKgKuen30TaorTNdDMgajpEmSy B673LCVUjiBMz5nwDwxX0ZS97epdVYP2qqaJXTbRTC64vldoUFM1ohLsSFsFY+HN Wbn9/xDl0WnqurnBkQd7g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegkedgudegudcutefuodetggdotefrod 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 15:33:56 -0400 (EDT) From: Thomas Monjalon To: Olivier Matz Cc: Shijith Thotton , dev@dpdk.org, pbhagavatula@marvell.com, Honnappa.Nagarahalli@arm.com, bruce.richardson@intel.com, jerinj@marvell.com, mb@smartsharesystems.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 21:33:54 +0200 Message-ID: <2275088.bcXerOTE6V@thomas> In-Reply-To: References: <20220907134340.3629224-1-sthotton@marvell.com> <5861713.UjTJXf6HLC@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 28/09/2022 14:52, Olivier Matz: > On Wed, Sep 28, 2022 at 09:24:51AM +0200, Thomas Monjalon wrote: > > 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. > > I don't think it is an issue. > > > 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. > > In general, I agree that we don't want to have many custom compile-time options, > especially if they impact ABI. It has several issues that have already been > widely discussed. > > However, in this specific case, we can suppose that removing buf_iova is a > long-term goal (in years). Having this compile-time option is a way to test this > approach, and progressively prepare the drivers to support it. Then, in few > years (if we are still convinced), we may announce an abi breakage and switch to > this new mode by default. You convinced me.