DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Chengwen Feng <fengchengwen@huawei.com>, thomas@monjalon.net
Cc: dev@dpdk.org, stephen@networkplumber.org
Subject: Re: [PATCH v3 1/5] kvargs: add one new process API
Date: Fri, 3 Nov 2023 13:09:37 +0000	[thread overview]
Message-ID: <8d4cbdbf-64fb-4d87-bbb0-ee6b203f66a0@amd.com> (raw)
In-Reply-To: <20231103073811.13196-2-fengchengwen@huawei.com>

On 11/3/2023 7:38 AM, Chengwen Feng wrote:
> The rte_kvargs_process() was used to parse key-value (e.g. socket_id=0),
> it also supports to parse only-key (e.g. socket_id). But many drivers's
> callback can only handle key-value, it will segment fault if handles
> only-key. so the patchset [1] was introduced.
> 
> Because the patchset [1] modified too much drivers, therefore:
> 1) A new API rte_kvargs_process_opt() was introduced, it inherits the
> function of rte_kvargs_process() which could parse both key-value and
> only-key.
> 2) Constraint the rte_kvargs_process() can only parse key-value.
> 

Hi Chengwen,

This works, but behavior change in 'rte_kvargs_process()' can hit some
exiting users who handles both "key=value" and "key" cases.

Other option is to keep 'rte_kvargs_process()' behavior same but add a
new API like 'rte_kvargs_process_safe()' that checks "value == NULL"
case, but this requires more existing code to change and in this option
existing users doesn't get the benefit of the NULL check by default.


Assuming number of the users that use 'rte_kvargs_process()' for
"key=value" is majority, OK to continue with your change, but please
document this in the release notes to highlight.



> [1] https://patches.dpdk.org/project/dpdk/patch/20230320092110.37295-1-fengchengwen@huawei.com/
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  lib/kvargs/rte_kvargs.c | 29 ++++++++++++++++++++++++++++-
>  lib/kvargs/rte_kvargs.h | 28 ++++++++++++++++++++++++++++
>  lib/kvargs/version.map  |  3 +++
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/kvargs/rte_kvargs.c b/lib/kvargs/rte_kvargs.c
> index c77bb82feb..5ce8664238 100644
> --- a/lib/kvargs/rte_kvargs.c
> +++ b/lib/kvargs/rte_kvargs.c
> @@ -168,7 +168,7 @@ rte_kvargs_count(const struct rte_kvargs *kvlist, const char *key_match)
>  }
>  
>  /*
> - * For each matching key, call the given handler function.
> + * For each matching key in key/value, call the given handler function.
>   */
>  int
>  rte_kvargs_process(const struct rte_kvargs *kvlist,
> @@ -179,6 +179,33 @@ rte_kvargs_process(const struct rte_kvargs *kvlist,
>  	const struct rte_kvargs_pair *pair;
>  	unsigned i;
>  
> +	if (kvlist == NULL)
> +		return 0;
> +

I think it should return error here, ignoring arg silently with success
can cause trouble in the application. If error returned, at least
application can know argument not provided as it should be (value is
missing).


> +	for (i = 0; i < kvlist->count; i++) {
> +		pair = &kvlist->pairs[i];
> +		if (pair->value == NULL)
> +			continue;
> +		if (key_match == NULL || strcmp(pair->key, key_match) == 0) {
> +			if ((*handler)(pair->key, pair->value, opaque_arg) < 0)
> +				return -1;
> +		}
> +	}
> +	return 0;
> +}
> +

'rte_kvargs_process()' & 'rte_kvargs_process_opt()' implementations are
very similar, to reduce duplication what about create
'rte_kvargs_process_common()' static function and both use this common
with different parameter?


> +/*
> + * For each matching key in key/value or only-key, call the given handler function.
> + */
> +int
> +rte_kvargs_process_opt(const struct rte_kvargs *kvlist,
> +		       const char *key_match,
> +		       arg_handler_t handler,
> +		       void *opaque_arg)
> +{
> +	const struct rte_kvargs_pair *pair;
> +	unsigned int i;
> +
>  	if (kvlist == NULL)
>  		return 0;
>  
> diff --git a/lib/kvargs/rte_kvargs.h b/lib/kvargs/rte_kvargs.h
> index 4900b750bc..522e83f757 100644
> --- a/lib/kvargs/rte_kvargs.h
> +++ b/lib/kvargs/rte_kvargs.h
> @@ -195,6 +195,34 @@ const char *rte_kvargs_get_with_value(const struct rte_kvargs *kvlist,
>  int rte_kvargs_process(const struct rte_kvargs *kvlist,
>  	const char *key_match, arg_handler_t handler, void *opaque_arg);
>  
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Call a handler function for each key/value or only-key matching the key
> + *
>

In API documentation, the difference between  'rte_kvargs_process_opt()'
& 'rte_kvargs_process()' is, 'rte_kvargs_process()' doesn't have "or
only-key", this is easy to miss.
Can you please add more not to 'rte_kvargs_process()' saying on
"only-key" case it returns error?


> + * For each key/value or only-key association that matches the given key, calls
> + * the handler function with the for a given arg_name passing the value on the
> + * dictionary for that key and a given extra argument.
> + *
> + * @param kvlist
> + *   The rte_kvargs structure. No error if NULL.
> + * @param key_match
> + *   The key on which the handler should be called, or NULL to process handler
> + *   on all associations
> + * @param handler
> + *   The function to call for each matching key
> + * @param opaque_arg
> + *   A pointer passed unchanged to the handler
> + *
> + * @return
> + *   - 0 on success
> + *   - Negative on error
> + */
> +__rte_experimental
> +int rte_kvargs_process_opt(const struct rte_kvargs *kvlist,
> +	const char *key_match, arg_handler_t handler, void *opaque_arg);
> +
>

I am not sure about the API name, 'rte_kvargs_process_opt()', what is
'opt' here, "optional"?
What about 'rte_kvargs_process_unsafe()', not quite strong on this too
but not able to come with better one, please feel free to try other
alternatives.


>  /**
>   * Count the number of associations matching the given key
>   *
> diff --git a/lib/kvargs/version.map b/lib/kvargs/version.map
> index 387a94e725..15d482e9b3 100644
> --- a/lib/kvargs/version.map
> +++ b/lib/kvargs/version.map
> @@ -16,4 +16,7 @@ EXPERIMENTAL {
>  
>  	# added in 21.11
>  	rte_kvargs_get_with_value;
> +
> +	# added in 23.11
> +	rte_kvargs_process_opt;
>  };


  reply	other threads:[~2023-11-03 13:09 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 12:48 [PATCH 0/5] fix segment fault when parse args Chengwen Feng
2023-03-14 12:48 ` [PATCH 1/5] app/pdump: " Chengwen Feng
2023-03-16 17:34   ` Ferruh Yigit
2023-03-14 12:48 ` [PATCH 2/5] net/memif: fix segment fault when parse devargs Chengwen Feng
2023-03-16 18:20   ` Ferruh Yigit
2023-03-14 12:48 ` [PATCH 3/5] net/pcap: " Chengwen Feng
2023-03-16 18:20   ` Ferruh Yigit
2023-03-14 12:48 ` [PATCH 4/5] net/ring: " Chengwen Feng
2023-03-14 12:48 ` [PATCH 5/5] net/sfc: " Chengwen Feng
2023-03-16 18:20   ` Ferruh Yigit
2023-03-16 18:18 ` [PATCH 0/5] fix segment fault when parse args Ferruh Yigit
2023-03-17  2:43   ` fengchengwen
2023-03-21 13:50     ` Ferruh Yigit
2023-03-22  1:15       ` fengchengwen
2023-03-22  8:53         ` Ferruh Yigit
2023-03-22 13:49           ` Thomas Monjalon
2023-03-23 11:58             ` fengchengwen
2023-03-23 12:51               ` Thomas Monjalon
2023-03-20  9:20 ` [PATCH v2 00/44] " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 01/44] app/pdump: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 02/44] ethdev: " Chengwen Feng
2023-04-09  8:10     ` Andrew Rybchenko
2023-03-20  9:20   ` [PATCH v2 03/44] net/memif: fix segment fault when parse devargs Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 04/44] net/pcap: " Chengwen Feng
2023-07-04  3:04     ` Stephen Hemminger
2023-03-20  9:20   ` [PATCH v2 05/44] net/ring: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 06/44] net/sfc: " Chengwen Feng
2023-04-09  8:09     ` Andrew Rybchenko
2023-03-20  9:20   ` [PATCH v2 07/44] net/af_xdp: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 08/44] net/ark: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 09/44] net/cnxk: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 10/44] net/cxgbe: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 11/44] net/dpaa2: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 12/44] net/ena: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 13/44] net/enic: " Chengwen Feng
2023-03-20 21:37     ` John Daley (johndale)
2023-03-20  9:20   ` [PATCH v2 14/44] net/fm10k: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 15/44] net/i40e: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 16/44] net/iavf: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 17/44] net/ice: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 18/44] net/idpf: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 19/44] net/ionic: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 20/44] net/mana: " Chengwen Feng
2023-03-21 22:19     ` Long Li
2023-03-20  9:20   ` [PATCH v2 21/44] net/mlx4: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 22/44] net/mvneta: " Chengwen Feng
2023-03-20  9:33     ` [EXT] " Liron Himi
2023-03-20  9:20   ` [PATCH v2 23/44] net/mvpp2: " Chengwen Feng
2023-03-20  9:33     ` [EXT] " Liron Himi
2023-03-20  9:20   ` [PATCH v2 24/44] net/netvsc: " Chengwen Feng
2023-03-21 22:20     ` Long Li
2023-07-04  3:02     ` Stephen Hemminger
2023-03-20  9:20   ` [PATCH v2 25/44] net/octeontx: " Chengwen Feng
2023-04-12  7:54     ` [EXT] " Harman Kalra
2023-03-20  9:20   ` [PATCH v2 26/44] net/pfe: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 27/44] net/qede: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 28/44] baseband/la12xx: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 29/44] bus/pci: fix segment fault when parse args Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 30/44] common/mlx5: fix segment fault when parse devargs Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 31/44] crypto/cnxk: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 32/44] crypto/dpaa_sec: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 33/44] crypto/dpaa2_sec: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 34/44] crypto/mvsam: " Chengwen Feng
2023-03-20  9:33     ` [EXT] " Liron Himi
2023-03-20  9:21   ` [PATCH v2 35/44] crypto/scheduler: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 36/44] dma/dpaa2: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 37/44] event/cnxk: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 38/44] event/dlb2: " Chengwen Feng
2023-03-24 16:26     ` Sevincer, Abdullah
2023-03-20  9:21   ` [PATCH v2 39/44] event/dpaa: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 40/44] event/octeontx: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 41/44] event/opdl: " Chengwen Feng
2023-03-23 13:48     ` Liang Ma
2023-03-20  9:21   ` [PATCH v2 42/44] event/sw: " Chengwen Feng
2023-03-20 11:58     ` Van Haaren, Harry
2023-03-20  9:21   ` [PATCH v2 43/44] mempool/cnxk: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 44/44] raw/cnxk_gpio: " Chengwen Feng
2023-04-15  1:38   ` [PATCH v2 00/44] fix segment fault when parse args fengchengwen
2023-04-17 16:37     ` Ferruh Yigit
2023-10-31 20:46       ` Stephen Hemminger
2023-10-31 20:58 ` [RFC] kvargs: don't pass parse handler a NULL pointer Stephen Hemminger
2023-11-01  1:16   ` fengchengwen
2023-11-03  7:38 ` [PATCH v3 0/5] fix segment fault when parse args Chengwen Feng
2023-11-03  7:38   ` [PATCH v3 1/5] kvargs: add one new process API Chengwen Feng
2023-11-03 13:09     ` Ferruh Yigit [this message]
2023-11-05  5:55       ` fengchengwen
2023-11-03  7:38   ` [PATCH v3 2/5] net/af_packet: use new API to parse kvargs Chengwen Feng
2023-11-03 13:11     ` Ferruh Yigit
2023-11-05  5:56       ` fengchengwen
2023-11-03  7:38   ` [PATCH v3 3/5] net/sfc: " Chengwen Feng
2023-11-03 13:23     ` Ferruh Yigit
2023-11-03  7:38   ` [PATCH v3 4/5] net/tap: " Chengwen Feng
2023-11-03 13:34     ` Ferruh Yigit
2023-11-05  5:57       ` fengchengwen
2023-11-03  7:38   ` [PATCH v3 5/5] net/mvneta: fix possible out-of-bounds write Chengwen Feng
2023-11-03 13:39     ` Ferruh Yigit
2023-11-03 13:41   ` [PATCH v3 0/5] fix segment fault when parse args Ferruh Yigit
2023-11-05  5:50     ` fengchengwen
2023-11-05  5:45 ` [PATCH v4 " Chengwen Feng
2023-11-05  5:45   ` [PATCH v4 1/5] kvargs: add one new process API Chengwen Feng
2023-11-06  3:18     ` Stephen Hemminger
2023-11-06  7:13       ` fengchengwen
2023-11-06 16:19         ` Stephen Hemminger
2023-11-07  3:21           ` fengchengwen
2023-11-05  5:45   ` [PATCH v4 2/5] net/sfc: use new API to parse kvargs Chengwen Feng
2023-11-05  5:45   ` [PATCH v4 3/5] net/tap: " Chengwen Feng
2023-11-05  5:45   ` [PATCH v4 4/5] common/nfp: " Chengwen Feng
2023-11-06  3:19     ` Stephen Hemminger
2023-11-06  7:22       ` fengchengwen
2023-11-05  5:45   ` [PATCH v4 5/5] net/mvneta: fix possible out-of-bounds write Chengwen Feng
2023-11-06  7:31 ` [PATCH v5 0/5] fix segment fault when parse args Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 1/5] kvargs: add one new process API Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 2/5] net/sfc: use new API to parse kvargs Chengwen Feng
2023-11-06 10:28     ` Andrew Rybchenko
2023-11-06 12:29       ` fengchengwen
2023-11-07  7:18         ` Andrew Rybchenko
2023-11-06  7:31   ` [PATCH v5 3/5] net/tap: " Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 4/5] common/nfp: " Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 5/5] net/mvneta: fix possible out-of-bounds write Chengwen Feng
2023-11-21  2:11     ` lihuisong (C)

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=8d4cbdbf-64fb-4d87-bbb0-ee6b203f66a0@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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).