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 50F44A0C53; Wed, 25 Aug 2021 10:01:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6BA3B411D0; Wed, 25 Aug 2021 10:01:40 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 12D45411C5 for ; Wed, 25 Aug 2021 10:01:38 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 53E90580CA0; Wed, 25 Aug 2021 04:01:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 25 Aug 2021 04:01:37 -0400 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= oRnFQoyv2cFvjhWhU295E2bpx/7znxi9PRcjXK1ma3o=; b=Wgq6CulAvDIJnW6i IIOD9C01MLZyCvYWObQ20wmftZgnR0ShqNuvkPJSA0iXw/up+zO+HgXdPM1YHM/H u8li1KunWklZB75S2RYl0EkH8mSTewdC1gwKr9mJWIFnnaMJsKJoDs3j6lrr0Bsa 24yZjbHwAdPAbh8+62tx2YEg14mzvdcPr7rA4NBwzfY5R9Gy291SIrqkntHPr4r/ ucwTxXKrNX+8CvYnH9N/ciHHnBi35Qm+EgFfumYCSivOdN5e3mbgEvHabTKkrxcZ uPRKYE+XsxMofoYXoM6KCNcEnJ8BpGAfGQMRz/PgDq/XArIguoZulqBQO622ClWM Re2S0g== 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=fm3; bh=oRnFQoyv2cFvjhWhU295E2bpx/7znxi9PRcjXK1ma 3o=; b=Ilpkhk2yO68DcwhT2RtoY3Vzt0c5FlmOp465hZUMMtHkN3fpnoFBnxA+b QOGzesOdimRDRmDvnGsQthAEMgYFcfknvHMsqNoANOKGFzTq4YD51LmCnc+Rsf3t 0xRRVODkHxDCBsf4uEqgaH4rfdRzNCK8dT3waK6PTLEreF7zZDM82LTD0bnagagy 0f3ZmEtX6V6PQtEn10bdzjgcvdRzCDNtH72jgTqqGnbYbPUf0XbMLRk4TXnzYTSQ oloBjSX3z0e995BvJo8uKrQEfNtQIAAbbsewCN6iH/lLhi7fmkSzwmHZUWZtresF lpQtPWYov0oZsYiMgaTb05T93kLoA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddtkedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 Aug 2021 04:01:34 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozlyuk Cc: "dev@dpdk.org" , Matan Azrad , Olivier Matz , Andrew Rybchenko , Slava Ovsiienko , david.marchand@redhat.com, maxime.coquelin@redhat.com, bruce.richardson@intel.com, ferruh.yigit@intel.com, anatoly.burakov@intel.com, jerinj@marvell.com, honnappa.nagarahalli@arm.com, ajit.khaparde@broadcom.com Date: Wed, 25 Aug 2021 10:01:33 +0200 Message-ID: <44052779.eynEIvlN4D@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] mempool: add non-IO flag 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 Sender: "dev" +1, I support this idea. 12/08/2021 14:43, Dmitry Kozlyuk: > We propose to add a mempool flag MEMPOOL_F_NON_IO to mark pools of objects that > will not be used with device IO and their memory for DMA. This will allow > saving IOMMU entries by not mapping the memory used by such pools. > > Immediate use case is MLX5 PMD. The hardware has its internal IOMMU where PMD > registers the memory. On the data path, PMD translates VA into a key consumed > by the device IOMMU. It is impractical for the PMD to register all allocated > memory because of increased lookup cost both in HW and SW. Most often mbuf > memory comes from mempools, so if PMD tracked them, it could almost always have > mbuf memory registered before an mbuf hits the PMD. The new flag would prevent > the PMD for registering memory that will never need it. Tracking the mempools > and dealing with them in MLX5 PMD is the next step after the proposed change. > > A possible use case is IOMMU management in EAL. Mempool could translate the new > flag to a hint to the memory manager, which would use it to skip adding IOMMU > entries in some cases. > > It was considered to add MEMPOOL_F_IO with the opposite meaning. It would be > automatically set for pktmbuf pools; user would be able to set it for other > pools. However, current assumption is that all DPDK memory is DMA-able, > it is controversial to have a flag asserting this fact.