All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Santosh Shukla <santosh.shukla@caviumnetworks.com>
Cc: dev@dpdk.org, hemant.agrawal@nxp.com, jerin.jacob@caviumnetworks.com
Subject: Re: [PATCH 1/2] eal: Introducing option to set mempool handle
Date: Fri, 30 Jun 2017 16:12:54 +0200	[thread overview]
Message-ID: <20170630161254.36730e2a@platinum> (raw)
In-Reply-To: <20170601080559.10684-2-santosh.shukla@caviumnetworks.com>

Hi Santosh,

On Thu,  1 Jun 2017 13:35:58 +0530, Santosh Shukla <santosh.shukla@caviumnetworks.com> wrote:
> Platform can have external PCI cards like Intel 40G card and
> Integrated NIC like OcteoTX. Where both NIC has their
> preferred pool handle. Example: Intel 40G NIC preferred pool
> is ring_mp_mc and OcteonTX preferred pool handle would be
> ext-mempool's handle named 'octeontx-fpavf'.
> 
> There is no way that either of NIC's could use their choice
> of mempool handle.
> 
> Because Currently mempool handle programmed in static way i.e.
> User has to set pool handle name in CONFIG_RTE_MEMPOOL_OPS_DEFAULT=''
> 
> So introducing eal option --pkt-mempool="".
> 
> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> ---
>  lib/librte_eal/bsdapp/eal/eal.c                 |  9 +++++++
>  lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  7 +++++
>  lib/librte_eal/common/eal_common_options.c      |  3 +++
>  lib/librte_eal/common/eal_internal_cfg.h        |  2 ++
>  lib/librte_eal/common/eal_options.h             |  2 ++
>  lib/librte_eal/common/include/rte_eal.h         |  9 +++++++
>  lib/librte_eal/linuxapp/eal/eal.c               | 36 +++++++++++++++++++++++++
>  lib/librte_eal/linuxapp/eal/rte_eal_version.map |  7 +++++
>  lib/librte_mbuf/rte_mbuf.c                      |  8 ++++--
>  9 files changed, 81 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> index 05f0c1f90..7d8824707 100644
> --- a/lib/librte_eal/bsdapp/eal/eal.c
> +++ b/lib/librte_eal/bsdapp/eal/eal.c
> @@ -113,6 +113,15 @@ struct internal_config internal_config;
>  /* used by rte_rdtsc() */
>  int rte_cycles_vmware_tsc_map;
>  
> +char *__rte_unused

why __rte_unused?
I'll also add a const

> +rte_eal_get_mp_name(void)

I suggest rte_eal_mbuf_default_mempool_ops()
It's longer but it shows it's only about mbufs, and it is consistent
with the #define.

> +{
> +	if (internal_config.mp_name[0] == 0x0)
> +		return NULL;
> +	else
> +		return internal_config.mp_name;
> +}
> +

Would returning RTE_MBUF_DEFAULT_MEMPOOL_OPS instead of NULL
make sense?


>  /* Return a pointer to the configuration structure */
>  struct rte_config *
>  rte_eal_get_configuration(void)
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index 2e48a7366..a1e9ad95f 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -193,3 +193,10 @@ DPDK_17.05 {
>  	vfio_get_group_no;
>  
>  } DPDK_17.02;
> +
> +DPDK_17.08 {
> +	global:
> +
> +	rte_eal_get_mp_name;
> +
> +} DPDK_17.05;
> diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
> index f470195f3..1c147a696 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -95,6 +95,7 @@ eal_long_options[] = {
>  	{OPT_VFIO_INTR,         1, NULL, OPT_VFIO_INTR_NUM        },
>  	{OPT_VMWARE_TSC_MAP,    0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
>  	{OPT_XEN_DOM0,          0, NULL, OPT_XEN_DOM0_NUM         },
> +	{OPT_PKT_MEMPOOL,       1, NULL, OPT_PKT_MEMPOOL_NUM      },
>  	{0,                     0, NULL, 0                        }
>  };
>  
> @@ -161,6 +162,7 @@ eal_reset_internal_config(struct internal_config *internal_cfg)
>  #endif
>  	internal_cfg->vmware_tsc_map = 0;
>  	internal_cfg->create_uio_dev = 0;
> +	memset(&internal_cfg->mp_name[0], 0x0, MAX_POOL_NAME_LEN);
>  }
>  
>  static int

Or it could be initialized to RTE_MBUF_DEFAULT_MEMPOOL_OPS here?

> @@ -1083,5 +1085,6 @@ eal_common_usage(void)
>  	       "  --"OPT_NO_PCI"            Disable PCI\n"
>  	       "  --"OPT_NO_HPET"           Disable HPET\n"
>  	       "  --"OPT_NO_SHCONF"         No shared config (mmap'd files)\n"
> +	       "  --"OPT_PKT_MEMPOOL"       Use pool name as mempool for port\n"
>  	       "\n", RTE_MAX_LCORE);
>  }
> diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
> index 7b7e8c887..b8fedd2e6 100644
> --- a/lib/librte_eal/common/eal_internal_cfg.h
> +++ b/lib/librte_eal/common/eal_internal_cfg.h
> @@ -43,6 +43,7 @@
>  #include <rte_pci_dev_feature_defs.h>
>  
>  #define MAX_HUGEPAGE_SIZES 3  /**< support up to 3 page sizes */
> +#define MAX_POOL_NAME_LEN 256 /**< Max len of a pool name */
>  
>  /*
>   * internal configuration structure for the number, size and

Shouldn't we have the same length than RTE_MEMPOOL_OPS_NAMESIZE?
I think we should try to avoid introducing new defines without
RTE_ prefix.


> @@ -84,6 +85,7 @@ struct internal_config {
>  	const char *hugepage_dir;         /**< specific hugetlbfs directory to use */
>  
>  	unsigned num_hugepage_sizes;      /**< how many sizes on this system */
> +	char mp_name[MAX_POOL_NAME_LEN];  /**< mempool handle name */
>  	struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES];
>  };

If it's in internal config, I think we can use a char pointer
instead of a table.

What is the expected behavior in case of multiprocess?


>  extern struct internal_config internal_config; /**< Global EAL configuration. */
> diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
> index a881c62e2..4e52ee255 100644
> --- a/lib/librte_eal/common/eal_options.h
> +++ b/lib/librte_eal/common/eal_options.h
> @@ -83,6 +83,8 @@ enum {
>  	OPT_VMWARE_TSC_MAP_NUM,
>  #define OPT_XEN_DOM0          "xen-dom0"
>  	OPT_XEN_DOM0_NUM,
> +#define OPT_PKT_MEMPOOL       "pkt-mempool"
> +	OPT_PKT_MEMPOOL_NUM,
>  	OPT_LONG_MAX_NUM
>  };
>  

While "pkt-mempool" is probably ok, here are some other suggestions,
in case you feel it's clearer:

 pkt-pool-ops
 mbuf-pool-ops
 mbuf-default-mempool-ops  (too long, but consistent with #define and api)


> diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
> index abf020bf9..c2f696a3d 100644
> --- a/lib/librte_eal/common/include/rte_eal.h
> +++ b/lib/librte_eal/common/include/rte_eal.h
> @@ -283,6 +283,15 @@ static inline int rte_gettid(void)
>  	return RTE_PER_LCORE(_thread_id);
>  }
>  
> +/**
> + * Get mempool name from cmdline.
> + *
> + * @return
> + *   On success, returns the pool name.
> + *   On Failure, returs NULL.
> + */
> +char *rte_eal_get_mp_name(void);
> +
>  #define RTE_INIT(func) \
>  static void __attribute__((constructor, used)) func(void)
>  
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> index 7c78f2dc2..b2a6c8068 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -122,6 +122,15 @@ struct internal_config internal_config;
>  /* used by rte_rdtsc() */
>  int rte_cycles_vmware_tsc_map;
>  
> +char *
> +rte_eal_get_mp_name(void)
> +{
> +	if (internal_config.mp_name[0] == 0x0)
> +		return NULL;
> +	else
> +		return internal_config.mp_name;
> +}
> +
>  /* Return a pointer to the configuration structure */
>  struct rte_config *
>  rte_eal_get_configuration(void)
> @@ -478,6 +487,23 @@ eal_parse_vfio_intr(const char *mode)
>  	return -1;
>  }
>  
> +static int
> +eal_parse_mp_name(const char *name)
> +{
> +	int len;
> +
> +	if (name == NULL)
> +		return -1;
> +
> +	len = strlen(name);
> +	if (len >= MAX_POOL_NAME_LEN)
> +		return -1;
> +
> +	strcpy(internal_config.mp_name, name);
> +
> +	return 0;
> +}
> +

Why is it linuxapp only?

Using strcpy() is not a good habbit, I suggest to use snprintf
instead. Also, prefer to use sizeof() instead of using the #define
size.


ret = snprintf(internal_config.mp_name, sizeof(internal_config.mp_name),
	"%s", name);
if (ret < 0 || ret >= sizeof(internal_config.mp_name))
	return -1;
return 0;


>  /* Parse the arguments for --log-level only */
>  static void
>  eal_log_level_parse(int argc, char **argv)
> @@ -611,6 +637,16 @@ eal_parse_args(int argc, char **argv)
>  			internal_config.create_uio_dev = 1;
>  			break;
>  
> +		case OPT_PKT_MEMPOOL_NUM:
> +			if (eal_parse_mp_name(optarg) < 0) {
> +				RTE_LOG(ERR, EAL, "invalid parameters for --"
> +						OPT_PKT_MEMPOOL "\n");
> +				eal_usage(prgname);
> +				ret = -1;
> +				goto out;
> +			}
> +			break;
> +
>  		default:
>  			if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
>  				RTE_LOG(ERR, EAL, "Option %c is not supported "
> diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> index 670bab3a5..e57330bec 100644
> --- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> @@ -198,3 +198,10 @@ DPDK_17.05 {
>  	vfio_get_group_no;
>  
>  } DPDK_17.02;
> +
> +DPDK_17.08 {
> +	global:
> +
> +	rte_eal_get_mp_name;
> +
> +} DPDK_17.05
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 0e3e36a58..38f4b3de0 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -158,6 +158,7 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
>  {
>  	struct rte_mempool *mp;
>  	struct rte_pktmbuf_pool_private mbp_priv;
> +	const char *mp_name = NULL;
>  	unsigned elt_size;
>  	int ret;
>  
> @@ -177,8 +178,11 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
>  	if (mp == NULL)
>  		return NULL;
>  
> -	ret = rte_mempool_set_ops_byname(mp,
> -		RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
> +	mp_name = rte_eal_get_mp_name();
> +	if (mp_name == NULL)
> +		mp_name = RTE_MBUF_DEFAULT_MEMPOOL_OPS;
> +
> +	ret = rte_mempool_set_ops_byname(mp, mp_name, NULL);
>  	if (ret != 0) {
>  		RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
>  		rte_mempool_free(mp);

If NULL is never returned, the code can be simplified a bit.


Olivier

  reply	other threads:[~2017-06-30 14:12 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01  8:05 [PATCH 0/2] Allow application set mempool handle Santosh Shukla
2017-06-01  8:05 ` [PATCH 1/2] eal: Introducing option to " Santosh Shukla
2017-06-30 14:12   ` Olivier Matz [this message]
2017-07-04 12:33     ` santosh
2017-06-01  8:05 ` [PATCH 2/2] ether/ethdev: Allow pmd to advertise preferred pool capability Santosh Shukla
2017-06-30 14:13   ` Olivier Matz
2017-07-04 12:39     ` santosh
2017-07-04 13:07       ` Olivier Matz
2017-07-04 14:12         ` Jerin Jacob
2017-06-19 11:52 ` [PATCH 0/2] Allow application set mempool handle Hemant Agrawal
2017-06-19 13:01   ` Jerin Jacob
2017-06-20 10:37     ` Hemant Agrawal
2017-06-20 14:04       ` Jerin Jacob
2017-06-30 14:12         ` Olivier Matz
2017-07-04 12:25           ` santosh
2017-07-04 15:59             ` Olivier Matz
2017-07-05  7:48               ` santosh
2017-07-20  7:06 ` [PATCH v2 0/2] Dynamically configure " Santosh Shukla
2017-07-20  7:06   ` [PATCH v2 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-08-15  8:07     ` [PATCH v3 0/2] Dynamically configure mempool handle Santosh Shukla
2017-08-15  8:07       ` [PATCH v3 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-09-04 11:46         ` Olivier MATZ
2017-09-07  9:25         ` Hemant Agrawal
2017-08-15  8:07       ` [PATCH v3 2/2] ethdev: allow pmd to advertise " Santosh Shukla
2017-09-04 12:11         ` Olivier MATZ
2017-09-04 13:14           ` santosh
2017-09-07  9:21             ` Hemant Agrawal
2017-09-07 10:06               ` santosh
2017-09-07 10:11                 ` santosh
2017-09-07 11:08                   ` Hemant Agrawal
2017-09-11  9:33                     ` Olivier MATZ
2017-09-11 12:40                       ` santosh
2017-09-11 13:00                         ` Olivier MATZ
2017-09-04  9:41       ` [PATCH v3 0/2] Dynamically configure mempool handle Sergio Gonzalez Monroy
2017-09-04 13:20         ` santosh
2017-09-04 13:34         ` Olivier MATZ
2017-09-04 14:24           ` Sergio Gonzalez Monroy
2017-09-05  7:47             ` Olivier MATZ
2017-09-05  8:11               ` Jerin Jacob
2017-09-11 15:18       ` [PATCH v4 " Santosh Shukla
2017-09-11 15:18         ` [PATCH v4 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-09-25  7:28           ` Olivier MATZ
2017-09-25 21:23             ` santosh
2017-09-11 15:18         ` [PATCH v4 2/2] ethdev: get the supported pools for a port Santosh Shukla
2017-09-25  7:37           ` Olivier MATZ
2017-09-25 21:52             ` santosh
2017-09-29  5:00               ` santosh
2017-09-29  8:32               ` Olivier MATZ
2017-09-29 10:16                 ` santosh
2017-09-29 11:21                   ` santosh
2017-09-29 11:23                   ` Olivier MATZ
2017-09-29 11:31                     ` santosh
2017-09-13 10:00         ` [PATCH v4 0/2] Dynamically configure mempool handle santosh
2017-09-19  8:28           ` santosh
2017-09-25  7:24             ` Olivier MATZ
2017-09-25 21:58               ` santosh
2017-10-01  9:14         ` [PATCH v5 " Santosh Shukla
2017-10-01  9:14           ` [PATCH v5 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-10-02 14:29             ` Olivier MATZ
2017-10-06  0:29             ` Thomas Monjalon
2017-10-06  3:31               ` santosh
2017-10-06  8:39                 ` Thomas Monjalon
2017-10-06  7:45             ` [PATCH v6 0/2] Dynamically configure mempool handle Santosh Shukla
2017-10-06  7:45               ` [PATCH v6 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-10-06  7:45               ` [PATCH v6 2/2] ethdev: get the supported pool for a port Santosh Shukla
2017-10-06 18:58               ` [PATCH v6 0/2] Dynamically configure mempool handle Thomas Monjalon
2017-10-01  9:14           ` [PATCH v5 2/2] ethdev: get the supported pool for a port Santosh Shukla
2017-10-02 14:31             ` Olivier MATZ
2017-10-06  0:30             ` Thomas Monjalon
2017-10-06  3:32               ` santosh
2017-10-02  8:37           ` [PATCH v5 0/2] Dynamically configure mempool handle santosh
2017-07-20  7:06   ` [PATCH v2 2/2] ethdev: allow pmd to advertise pool handle Santosh Shukla

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=20170630161254.36730e2a@platinum \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=santosh.shukla@caviumnetworks.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.