From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8F77BA0540; Mon, 4 Jul 2022 16:00:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3960D410E5; Mon, 4 Jul 2022 16:00:45 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 4600540E09 for <dev@dpdk.org>; Mon, 4 Jul 2022 16:00:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656943243; x=1688479243; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=mAhBBpUjxchvMvPQJVfpEjY94XurTQ2VsK0Hellj9xE=; b=nnBgV6INz0rZXuifeYznZ4rNiK/K/WDukRQ/SNBoZ3OC1o9L5MsEjPfO 6KhoncK5zkG7sWI0HW5FmH9H4Hnox/ABAY/AfO+WQhhOd5SodF72M4Utm +q1al1ne60wkS9vUPdKNdrCNj7H0p9FQPsWAAfA6aq8yMmZlB5f09zaA4 el+WAFENzdfFPCwgx82/EA1m8s/VY1V6wMfxvNAs2VrwQyTty3Jz4jV0y PPaxesLAyh+uY2RYuuMZQszIyntNIlpomNTGPG654L9C59bg0nnPskLEP wby0Xhol+X2uqoTUb8QO+GSzwjQuIVjV9L2/HWC4t/sQskU6Pg0ccvsbo w==; X-IronPort-AV: E=McAfee;i="6400,9594,10397"; a="266160467" X-IronPort-AV: E=Sophos;i="5.92,243,1650956400"; d="scan'208";a="266160467" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jul 2022 07:00:42 -0700 X-IronPort-AV: E=Sophos;i="5.92,243,1650956400"; d="scan'208";a="567237981" Received: from bricha3-mobl.ger.corp.intel.com ([10.55.133.37]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 04 Jul 2022 07:00:40 -0700 Date: Mon, 4 Jul 2022 15:00:37 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Morten =?iso-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> Cc: Shijith Thotton <sthotton@marvell.com>, stephen@networkplumber.org, olivier.matz@6wind.com, dev@dpdk.org, jerinj@marvell.com, thomas@monjalon.net, Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> Subject: Re: [PATCH] mbuf: add mbuf physical address field to dynamic field Message-ID: <YsLyhTNSSLN9vAv+@bricha3-MOBL.ger.corp.intel.com> References: <20220630094538.5b27d0c6@hermes.local> <20220701122434.1887783-1-sthotton@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35D871A4@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D871A4@smartserver.smartshare.dk> X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Sun, Jul 03, 2022 at 09:31:01AM +0200, Morten Brørup wrote: > > From: Shijith Thotton [mailto:sthotton@marvell.com] > > Sent: Friday, 1 July 2022 14.25 > > > > >> If all devices are configured to run in IOVA mode as VA, physical > > >> address field of mbuf (buf_iova) won't be used. > > Will some of the hardware vendors please comment on this: Has IOVA VA mode become common over time, or is it still an exotic bleeding edge feature? > > If it has become common, we should let DPDK evolve accordingly, and consider PA (non-VA) mode legacy, treating it as such. Don't get stuck in the past. > IOVA as VA mode is indeed common and we are constantly encouraging users to switch to using vfio to try and take advantage of this. However, in my experience IOVA as PA is still very, very common too. We cannot drop support for this mode just yet, unfortunately. > > >> In such cases, > > buf_iova > > >> space is free to use as a dynamic field. So a new dynamic field > > member > > >> (dynfield2) is added in mbuf structure to make use of that space. > > >> > > >> A new mbuf flag RTE_MBUF_F_DYNFIELD2 is introduced to help identify > > the > > >> mbuf that can use dynfield2. > > >> > > >> Signed-off-by: Shijith Thotton <sthotton@marvell.com> > > > > > > This seems like a complex and potentially error prone way to do this. > > Perhaps this optimization should be a compile time option instead? > It could indeed be, and probably could be done very safely, in that we could mark as disabled all drivers when the mode is enabled for a build. Thereafter, drivers could be marked as VA-only safe as they are updated as necessary, i.e. use the build system to enforce that only drivers known to work with the mode are built when the mode is enabled. That said, verifying all drivers to work with this mode is a decent effort. Do we have indications of the perf benefit we would get from doing this for some real-world app? /Bruce