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 36BA4A0C41; Wed, 25 Aug 2021 19:28:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CFA6B40041; Wed, 25 Aug 2021 19:28:46 +0200 (CEST) Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by mails.dpdk.org (Postfix) with ESMTP id 223F34003D for ; Wed, 25 Aug 2021 19:28:45 +0200 (CEST) Received: by mail-qv1-f44.google.com with SMTP id g11so416492qvd.2 for ; Wed, 25 Aug 2021 10:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xDFMSZAOG5OJ9B4X9BIi08+XMxYFka0dti5b9lL2ifs=; b=JQjQOshhUftT4TQubBSSe5f+80YLxMGAOhSR76NENqxlqEfFtk7yRZ4LecAQ9lo4W7 E0lCNVCCUdhoxVQTgavT0aDaScjIrn2ans6jVQICEkW6EHQE9jXDhxK98PQ9YRhwkBB1 ro6JK7GeawyHQbRZmbfA4m6CQqtAv2FlJw2Mc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xDFMSZAOG5OJ9B4X9BIi08+XMxYFka0dti5b9lL2ifs=; b=uKEgAzQpQtAbe7a879AuR87spTS9KZYrwi4WJyGVHoSf7/M9f1kDUe69h6Bl+limC3 toIOo6pWsRxI77srepP+s5WfZ1XybsSUB1IlTcFDDfIeatHl4ln6TaNM6gZPeh1Z9qmf dUStBlXJ9ohDv4ATwRARKNW4SvN8mBFvUb87RsCobSpi8q04AlNmgSiOvlkG12V+LyL+ wQ9vNwLeoLJeRpnW+uaVRO4CgMXViaKSHKxnM6MEe+Ltm2Z32uSbNJMxh5uNhAU2VWyh LH8Jdm9m0NCgoS1Fhi/PNOEBskA4R5iLn3YM3uu1xog5OiB+8dZaKKeBvTFDREN9kJ6V fM2A== X-Gm-Message-State: AOAM530bfWVrQWUV+tOXi8gy4KnnGOyxa8NdnP1p+T6lcdVrerE6P7tl PIVXhif3xqzU7xRX0OIZ6zFER+BSLZsE4kXFbFzS83u4ewU= X-Google-Smtp-Source: ABdhPJzmOU5foqE76iqf3oAUvb1q7zYIoFujwsgdf63/iEn3ZgJO8N6VvDiGrM/DRdR6znh+/EdFCwpYpfY0u/u4Xjw= X-Received: by 2002:a05:6214:2609:: with SMTP id gu9mr43993788qvb.35.1629912524342; Wed, 25 Aug 2021 10:28:44 -0700 (PDT) MIME-Version: 1.0 References: <44052779.eynEIvlN4D@thomas> In-Reply-To: <44052779.eynEIvlN4D@thomas> From: Ajit Khaparde Date: Wed, 25 Aug 2021 10:28:27 -0700 Message-ID: To: Thomas Monjalon Cc: Dmitry Kozlyuk , "dev@dpdk.org" , Matan Azrad , Olivier Matz , Andrew Rybchenko , Slava Ovsiienko , David Marchand , Maxime Coquelin , Bruce Richardson , Ferruh Yigit , Anatoly Burakov , Jerin Jacob Kollanukkaran , Honnappa Nagarahalli Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000cd81e05ca6595e8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --0000000000000cd81e05ca6595e8 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 25, 2021 at 1:01 AM Thomas Monjalon wrote: > > +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. +1 > > > > 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. +1 > > --0000000000000cd81e05ca6595e8--