DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Igor Ryzhov <iryzhov@nfware.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] kni: dynamically allocate memory for each KNI
Date: Mon, 27 Aug 2018 18:06:33 +0100	[thread overview]
Message-ID: <0b076a74-579e-5a63-d232-1afc791fb4cd@intel.com> (raw)
In-Reply-To: <20180802142522.57900-1-iryzhov@nfware.com>

On 8/2/2018 3:25 PM, Igor Ryzhov wrote:
> Long time ago preallocation of memory for KNI was introduced in commit
> 0c6bc8e. It was done because of lack of ability to free previously
> allocated memzones, which led to memzone exhaustion. Currently memzones
> can be freed and this patch uses this ability for dynamic KNI memory
> allocation.

Hi Igor,

It is good to be able to allocate memory dynamically and get rid of the
"max_kni_ifaces" and "kni_memzone_pool", thanks for the patch.

Overall looks good, a few comments below.

> 
> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
> ---
>  lib/librte_kni/rte_kni.c | 392 ++++++++++++---------------------------
>  lib/librte_kni/rte_kni.h |   6 +-
>  test/test/test_kni.c     |   6 -
>  3 files changed, 128 insertions(+), 276 deletions(-)
> 
> diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
> index 8a8f6c1cc..028b44bfd 100644
> --- a/lib/librte_kni/rte_kni.c
> +++ b/lib/librte_kni/rte_kni.c
> @@ -36,24 +36,33 @@
>   * KNI context
>   */
>  struct rte_kni {
> +	const struct rte_memzone *mz;       /**< KNI context memzone */

I was thinking remove the context memzone and use rte_zmalloc() to create kni
objects but updated rte_kni_get() API seems relaying this.
If you see any other way to get kni object from name in rte_kni_get(), I am for
removing above *mz variable from rte_kni struct.

<...>

> +static void
> +kni_ctx_release_mz(struct rte_kni *ctx)
> +{
> +	rte_memzone_free(ctx->m_tx_q);
> +	rte_memzone_free(ctx->m_rx_q);
> +	rte_memzone_free(ctx->m_alloc_q);
> +	rte_memzone_free(ctx->m_free_q);
> +	rte_memzone_free(ctx->m_req_q);
> +	rte_memzone_free(ctx->m_resp_q);
> +	rte_memzone_free(ctx->m_sync_addr);


"ctx" sounds confusing to me, isn't this "rte_kni" object instance, why not just
call it "kni" or if it is too generic "kni_obj" or similar? For other APIs as well.

And this is just a detail but about order of APIs would you mind having first
reserve() one, later release() one?

<...>

> -/* Shall be called before any allocation happens */
> -void
> -rte_kni_init(unsigned int max_kni_ifaces)
> +static struct rte_kni *
> +kni_ctx_reserve(const char *name)
>  {
> -	uint32_t i;
> -	struct rte_kni_memzone_slot *it;
> +	struct rte_kni *ctx;
>  	const struct rte_memzone *mz;
> -#define OBJNAMSIZ 32
> -	char obj_name[OBJNAMSIZ];
>  	char mz_name[RTE_MEMZONE_NAMESIZE];
>  
> -	/* Immediately return if KNI is already initialized */
> -	if (kni_memzone_pool.initialized) {
> -		RTE_LOG(WARNING, KNI, "Double call to rte_kni_init()");
> -		return;
> -	}
> +	snprintf(mz_name, RTE_MEMZONE_NAMESIZE, "kni_info_%s", name);

Can you please convert memzone names, like "kni_info" to defines, for all of them?

<...>

> @@ -81,8 +81,12 @@ struct rte_kni_conf {
>   *
>   * @param max_kni_ifaces
>   *  The maximum number of KNI interfaces that can coexist concurrently
> + *
> + * @return
> + *  - 0 indicates success.
> + *  - negative value indicates failure.
>   */
> -void rte_kni_init(unsigned int max_kni_ifaces);
> +int rte_kni_init(unsigned int max_kni_ifaces);

This changes the API. Return type changes from "void" to "int". I agree "int"
makes more sense since API can fail, but this changes the ABI/API.

Since existing binaries doesn't check the return type at all there may be no
issue from ABI point of view but from API point of view some apps may get return
value not checked warnings, not sure though.

And the need of the API is questionable at this stage, it may be possible to
move rte_kni_alloc() where it already has "kni_fd" check.

What do you think keep API signature same for now, but add a deprecation notice
to remove the API. Next release (v19.02) remove rte_kni_init() completely?

<...>

>  /**
> diff --git a/test/test/test_kni.c b/test/test/test_kni.c
> index 1b876719a..56c98513a 100644
> --- a/test/test/test_kni.c
> +++ b/test/test/test_kni.c
> @@ -429,12 +429,6 @@ test_kni_processing(uint16_t port_id, struct rte_mempool *mp)
>  	}
>  	test_kni_ctx = NULL;
>  
> -	/* test of releasing a released kni device */
> -	if (rte_kni_release(kni) == 0) {
> -		printf("should not release a released kni device\n");
> -		return -1;
> -	}

Why need to remove this?

  reply	other threads:[~2018-08-27 17:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 14:25 Igor Ryzhov
2018-08-27 17:06 ` Ferruh Yigit [this message]
2018-08-29  9:52   ` Igor Ryzhov
2018-08-30 10:55     ` Ferruh Yigit
2018-09-23 19:12 ` [dpdk-dev] [PATCH v2] " Igor Ryzhov
2018-09-26 10:41   ` Ferruh Yigit
2018-09-26 13:31     ` Igor Ryzhov
2018-09-26 16:21   ` [dpdk-dev] [PATCH v3] " Igor Ryzhov
2018-09-27 19:20     ` Ferruh Yigit
2018-10-02 13:06     ` Thomas Monjalon
2018-10-02 13:27       ` Ferruh Yigit
2018-10-02 13:27         ` Ferruh Yigit
2018-10-02 15:29     ` Thomas Monjalon

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=0b076a74-579e-5a63-d232-1afc791fb4cd@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=iryzhov@nfware.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).