From: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Matan Azrad <matan@nvidia.com>,
Olivier Matz <olivier.matz@6wind.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Slava Ovsiienko <viacheslavo@nvidia.com>,
Thomas Monjalon <tmonjalon@nvidia.com>
Subject: [dpdk-dev] [RFC] mempool: add non-IO flag
Date: Thu, 12 Aug 2021 12:43:01 +0000 [thread overview]
Message-ID: <CH0PR12MB509112FADB778AB28AF3771DB9F99@CH0PR12MB5091.namprd12.prod.outlook.com> (raw)
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 reply other threads:[~2021-08-12 12:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 12:43 Dmitry Kozlyuk [this message]
2021-08-25 8:01 ` Thomas Monjalon
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=CH0PR12MB509112FADB778AB28AF3771DB9F99@CH0PR12MB5091.namprd12.prod.outlook.com \
--to=dkozlyuk@nvidia.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=matan@nvidia.com \
--cc=olivier.matz@6wind.com \
--cc=tmonjalon@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).