From: Thomas Monjalon <thomas@monjalon.net>
To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Matan Azrad <matan@nvidia.com>,
Olivier Matz <olivier.matz@6wind.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Slava Ovsiienko <viacheslavo@nvidia.com>,
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
Subject: Re: [dpdk-dev] [RFC] mempool: add non-IO flag
Date: Wed, 25 Aug 2021 10:01:33 +0200 [thread overview]
Message-ID: <44052779.eynEIvlN4D@thomas> (raw)
In-Reply-To: <CH0PR12MB509112FADB778AB28AF3771DB9F99@CH0PR12MB5091.namprd12.prod.outlook.com>
+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.
next prev parent reply other threads:[~2021-08-25 8:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 12:43 [dpdk-dev] [RFC] mempool: add non-IO flag Dmitry Kozlyuk
2021-08-25 8:01 ` Thomas Monjalon [this message]
2021-08-25 17:28 ` Ajit Khaparde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44052779.eynEIvlN4D@thomas \
--to=thomas@monjalon.net \
--cc=ajit.khaparde@broadcom.com \
--cc=anatoly.burakov@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dkozlyuk@nvidia.com \
--cc=ferruh.yigit@intel.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=matan@nvidia.com \
--cc=maxime.coquelin@redhat.com \
--cc=olivier.matz@6wind.com \
--cc=viacheslavo@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.