From: Yongseok Koh <yskoh@mellanox.com>
To: shahafs@mellanox.com
Cc: dev@dpdk.org
Subject: [dpdk-dev] [PATCH v2 3/6] net/mlx5: add control of excessive memory pinning by kernel
Date: Mon, 25 Mar 2019 12:22:35 -0700 [thread overview]
Message-ID: <20190325192238.20940-4-yskoh@mellanox.com> (raw)
In-Reply-To: <20190325192238.20940-1-yskoh@mellanox.com>
A new PMD parameter (mr_ext_memseg_en) is added to control extension of
memseg when creating a MR. It is enabled by default.
If enabled, mlx5_mr_create() tries to maximize the range of MR
registration so that the LKey lookup tables on datapath become smaller and
get the best performance. However, it may worsen memory utilization
because registered memory is pinned by kernel driver. Even if a page in the
extended chunk is freed, that doesn't become reusable until the entire
memory is freed and the MR is destroyed.
To make freed pages available immediately, this parameter has to be turned
off but it could drop performance.
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Shahaf Shuler <shahafs@mellanox.com>
---
doc/guides/nics/mlx5.rst | 11 +++++++++++
drivers/net/mlx5/mlx5.c | 7 +++++++
drivers/net/mlx5/mlx5.h | 2 ++
drivers/net/mlx5/mlx5_mr.c | 21 ++++++++++++++++-----
4 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index cbe3fb4c33..d9ae91dfc1 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -485,6 +485,17 @@ Run-time configuration
Disabled by default.
+- ``mr_ext_memseg_en`` parameter [int]
+
+ A nonzero value enables extending memseg when registering DMA memory. If
+ enabled, the number of entries in MR (Memory Region) lookup table on datapath
+ is minimized and it benefits performance. On the other hand, it worsens memory
+ utilization because registered memory is pinned by kernel driver. Even if a
+ page in the extended chunk is freed, that doesn't become reusable until the
+ entire memory is freed.
+
+ Enabled by default.
+
- ``representor`` parameter [list]
This parameter can be used to instantiate DPDK Ethernet devices from
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 840cd3d307..93c0fc8c20 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -108,6 +108,9 @@
/* Activate Netlink support in VF mode. */
#define MLX5_VF_NL_EN "vf_nl_en"
+/* Enable extending memsegs when creating a MR. */
+#define MLX5_MR_EXT_MEMSEG_EN "mr_ext_memseg_en"
+
/* Select port representors to instantiate. */
#define MLX5_REPRESENTOR "representor"
@@ -569,6 +572,8 @@ mlx5_args_check(const char *key, const char *val, void *opaque)
config->vf_nl_en = !!tmp;
} else if (strcmp(MLX5_DV_FLOW_EN, key) == 0) {
config->dv_flow_en = !!tmp;
+ } else if (strcmp(MLX5_MR_EXT_MEMSEG_EN, key) == 0) {
+ config->mr_ext_memseg_en = !!tmp;
} else {
DRV_LOG(WARNING, "%s: unknown parameter", key);
rte_errno = EINVAL;
@@ -610,6 +615,7 @@ mlx5_args(struct mlx5_dev_config *config, struct rte_devargs *devargs)
MLX5_L3_VXLAN_EN,
MLX5_VF_NL_EN,
MLX5_DV_FLOW_EN,
+ MLX5_MR_EXT_MEMSEG_EN,
MLX5_REPRESENTOR,
NULL,
};
@@ -1588,6 +1594,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
.txqs_vec = MLX5_ARG_UNSET,
.inline_max_packet_sz = MLX5_ARG_UNSET,
.vf_nl_en = 1,
+ .mr_ext_memseg_en = 1,
.mprq = {
.enabled = 0, /* Disabled by default. */
.stride_num_n = MLX5_MPRQ_STRIDE_NUM_N,
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index d8a5162bdb..37c8cd1d34 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -167,6 +167,8 @@ struct mlx5_dev_config {
unsigned int tx_vec_en:1; /* Tx vector is enabled. */
unsigned int rx_vec_en:1; /* Rx vector is enabled. */
unsigned int mpw_hdr_dseg:1; /* Enable DSEGs in the title WQEBB. */
+ unsigned int mr_ext_memseg_en:1;
+ /* Whether memseg should be extended for MR creation. */
unsigned int l3_vxlan_en:1; /* Enable L3 VXLAN flow creation. */
unsigned int vf_nl_en:1; /* Enable Netlink requests in VF mode. */
unsigned int dv_flow_en:1; /* Enable DV flow. */
diff --git a/drivers/net/mlx5/mlx5_mr.c b/drivers/net/mlx5/mlx5_mr.c
index e255650add..e9eda975ff 100644
--- a/drivers/net/mlx5/mlx5_mr.c
+++ b/drivers/net/mlx5/mlx5_mr.c
@@ -534,6 +534,7 @@ mlx5_mr_create(struct rte_eth_dev *dev, struct mlx5_mr_cache *entry,
uintptr_t addr)
{
struct mlx5_priv *priv = dev->data->dev_private;
+ struct mlx5_dev_config *config = &priv->config;
struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
const struct rte_memseg_list *msl;
const struct rte_memseg *ms;
@@ -569,14 +570,24 @@ mlx5_mr_create(struct rte_eth_dev *dev, struct mlx5_mr_cache *entry,
*/
mlx5_mr_garbage_collect(dev);
/*
- * Find out a contiguous virtual address chunk in use, to which the
- * given address belongs, in order to register maximum range. In the
- * best case where mempools are not dynamically recreated and
+ * If enabled, find out a contiguous virtual address chunk in use, to
+ * which the given address belongs, in order to register maximum range.
+ * In the best case where mempools are not dynamically recreated and
* '--socket-mem' is specified as an EAL option, it is very likely to
* have only one MR(LKey) per a socket and per a hugepage-size even
- * though the system memory is highly fragmented.
+ * though the system memory is highly fragmented. As the whole memory
+ * chunk will be pinned by kernel, it can't be reused unless entire
+ * chunk is freed from EAL.
+ *
+ * If disabled, just register one memseg (page). Then, memory
+ * consumption will be minimized but it may drop performance if there
+ * are many MRs to lookup on the datapath.
*/
- if (!rte_memseg_contig_walk(mr_find_contig_memsegs_cb, &data)) {
+ if (!config->mr_ext_memseg_en) {
+ data.msl = rte_mem_virt2memseg_list((void *)addr);
+ data.start = RTE_ALIGN_FLOOR(addr, data.msl->page_sz);
+ data.end = data.start + data.msl->page_sz;
+ } else if (!rte_memseg_contig_walk(mr_find_contig_memsegs_cb, &data)) {
DRV_LOG(WARNING,
"port %u unable to find virtually contiguous"
" chunk for address (%p)."
--
2.11.0
next prev parent reply other threads:[~2019-03-25 19:22 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-07 7:41 [dpdk-dev] [PATCH 0/6] net/mlx: enable secondary process to register DMA memory Yongseok Koh
2019-03-07 7:41 ` [dpdk-dev] [PATCH 1/6] net/mlx: remove debug messages on datapath Yongseok Koh
2019-03-07 7:41 ` [dpdk-dev] [PATCH 2/6] net/mlx5: fix external memory registration Yongseok Koh
2019-03-07 7:41 ` [dpdk-dev] [PATCH 3/6] net/mlx5: add control of excessive memory pinning by kernel Yongseok Koh
2019-03-07 7:41 ` [dpdk-dev] [PATCH 4/6] net/mlx5: enable secondary process to register DMA memory Yongseok Koh
2019-03-07 7:41 ` [dpdk-dev] [PATCH 5/6] net/mlx4: add control of excessive memory pinning by kernel Yongseok Koh
2019-03-07 7:41 ` [dpdk-dev] [PATCH 6/6] net/mlx4: enable secondary process to register DMA memory Yongseok Koh
2019-03-07 7:55 ` [dpdk-dev] [PATCH 0/6] net/mlx: " Yongseok Koh
2019-03-14 12:45 ` Shahaf Shuler
2019-03-14 12:45 ` Shahaf Shuler
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 " Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 1/6] net/mlx: remove debug messages on datapath Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 2/6] net/mlx5: fix external memory registration Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh [this message]
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 3/6] net/mlx5: add control of excessive memory pinning by kernel Yongseok Koh
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 4/6] net/mlx5: enable secondary process to register DMA memory Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 5/6] net/mlx4: add control of excessive memory pinning by kernel Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh
2019-03-25 19:22 ` [dpdk-dev] [PATCH v2 6/6] net/mlx4: enable secondary process to register DMA memory Yongseok Koh
2019-03-25 19:22 ` Yongseok Koh
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 0/6] net/mlx: " Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 1/6] net/mlx: remove debug messages on datapath Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 2/6] net/mlx5: fix external memory registration Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 3/6] net/mlx5: add control of excessive memory pinning by kernel Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 4/6] net/mlx5: enable secondary process to register DMA memory Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 5/6] net/mlx4: add control of excessive memory pinning by kernel Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-05-14 4:52 ` Stephen Hemminger
2019-05-14 4:52 ` Stephen Hemminger
2019-05-14 4:54 ` Stephen Hemminger
2019-05-14 4:54 ` Stephen Hemminger
2019-04-01 21:17 ` [dpdk-dev] [PATCH v3 6/6] net/mlx4: enable secondary process to register DMA memory Yongseok Koh
2019-04-01 21:17 ` Yongseok Koh
2019-04-02 7:13 ` [dpdk-dev] [PATCH v3 0/6] net/mlx: " Shahaf Shuler
2019-04-02 7:13 ` Shahaf Shuler
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=20190325192238.20940-4-yskoh@mellanox.com \
--to=yskoh@mellanox.com \
--cc=dev@dpdk.org \
--cc=shahafs@mellanox.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).