From: David Marchand <david.marchand@redhat.com>
To: Chengwen Feng <fengchengwen@huawei.com>
Cc: thomas@monjalon.net, ferruh.yigit@amd.com, dev@dpdk.org,
Gagandeep Singh <g.singh@nxp.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Nicolas Chautru <nicolas.chautru@intel.com>,
Rosen Xu <rosen.xu@intel.com>, Kai Ji <kai.ji@intel.com>,
Kevin Laatz <kevin.laatz@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Abdullah Sevincer <abdullah.sevincer@intel.com>,
Srikanth Yalavarthi <syalavarthi@marvell.com>,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Somnath Kotur <somnath.kotur@broadcom.com>,
Chas Williams <chas3@att.com>,
"Min Hu (Connor)" <humin29@huawei.com>,
Gaetan Rivet <grive@u256.net>, Jie Hai <haijie1@huawei.com>,
Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
Ian Stokes <ian.stokes@intel.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Chaoyong He <chaoyong.he@corigine.com>,
Christian Koue Muf <ckm@napatech.com>,
Serhii Iliushyk <sil-plv@napatech.com>,
Tetsuya Mukawa <mtetsuyah@gmail.com>,
Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Jiawen Wu <jiawenwu@trustnetic.com>,
Jian Wang <jianwang@trustnetic.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
Chenbo Xia <chenbox@nvidia.com>,
Sachin Saxena <sachin.saxena@nxp.com>,
Vijay Kumar Srivastava <vsrivast@xilinx.com>,
Fan Zhang <fanzhang.oss@gmail.com>,
Ashish Gupta <ashish.gupta@marvell.com>,
Akhil Goyal <gakhil@marvell.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [PATCH] dpdk: remove redundant null check when parse kvargs
Date: Tue, 5 Nov 2024 22:02:24 +0100 [thread overview]
Message-ID: <CAJFAV8wrb7_3CUYN9ftL=i0s4w_LmED7tu4Xcz0cUzbkzMXUXg@mail.gmail.com> (raw)
In-Reply-To: <20241030040109.34504-1-fengchengwen@huawei.com>
Hello,
On Wed, Oct 30, 2024 at 5:00 AM Chengwen Feng <fengchengwen@huawei.com> wrote:
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 36b06b3ac5..9366cb39b8 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -2484,19 +2484,19 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev)
> }
>
> if (rte_kvargs_count(kvlist, ETH_TAP_REMOTE_ARG) == 1) {
> - ret = rte_kvargs_process(kvlist,
> - ETH_TAP_REMOTE_ARG,
> - &set_remote_iface,
> - remote_iface);
> + ret = rte_kvargs_process_opt(kvlist,
> + ETH_TAP_REMOTE_ARG,
> + &set_remote_iface,
> + remote_iface);
> if (ret == -1)
> goto leave;
> }
>
> if (rte_kvargs_count(kvlist, ETH_TAP_MAC_ARG) == 1) {
> - ret = rte_kvargs_process(kvlist,
> - ETH_TAP_MAC_ARG,
> - &set_mac_type,
> - &user_mac);
> + ret = rte_kvargs_process_opt(kvlist,
> + ETH_TAP_MAC_ARG,
> + &set_mac_type,
> + &user_mac);
> if (ret == -1)
> goto leave;
> }
Ok, it restores compatibility with some strange arguments passed by
user (and, on the principle, for this reason, it should be in a
separate commit with a Fixes: de89988365a7 ("kvargs: rework process
API")).
But on the other hand, this case does not make sense.
Those two helpers do nothing if there is no value.
Plus, those arguments are documented as taking a value:
ETH_TAP_MAC_ARG "=" ETH_TAP_MAC_ARG_FMT
" "
ETH_TAP_REMOTE_ARG "=<string>");
So in the end, the current logic looks more like an oversight in the
code, and the case "only key" should be rightfully rejected.
IOW: I would keep rte_kvargs_process() for them, but remove checks on
value == NULL in those two helpers.
Extract:
static int
set_mac_type(const char *key __rte_unused,
const char *value,
void *extra_args)
{
struct rte_ether_addr *user_mac = extra_args;
if (!value)
return 0;
...
}
static int
set_remote_iface(const char *key __rte_unused,
const char *value,
void *extra_args)
{
char *name = (char *)extra_args;
if (value) {
...
}
return 0;
}
The rest of the patch looks correct to me, and I did not spot a missed update.
Thanks.
--
David Marchand
prev parent reply other threads:[~2024-11-05 21:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 4:01 Chengwen Feng
2024-11-05 21:02 ` David Marchand [this message]
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='CAJFAV8wrb7_3CUYN9ftL=i0s4w_LmED7tu4Xcz0cUzbkzMXUXg@mail.gmail.com' \
--to=david.marchand@redhat.com \
--cc=abdullah.sevincer@intel.com \
--cc=ajit.khaparde@broadcom.com \
--cc=anatoly.burakov@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=ashish.gupta@marvell.com \
--cc=bruce.richardson@intel.com \
--cc=chaoyong.he@corigine.com \
--cc=chas3@att.com \
--cc=chenbox@nvidia.com \
--cc=ckm@napatech.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=fanzhang.oss@gmail.com \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=g.singh@nxp.com \
--cc=gakhil@marvell.com \
--cc=grive@u256.net \
--cc=haijie1@huawei.com \
--cc=hemant.agrawal@nxp.com \
--cc=humin29@huawei.com \
--cc=ian.stokes@intel.com \
--cc=jianwang@trustnetic.com \
--cc=jiawenwu@trustnetic.com \
--cc=kai.ji@intel.com \
--cc=kevin.laatz@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=mtetsuyah@gmail.com \
--cc=nicolas.chautru@intel.com \
--cc=rosen.xu@intel.com \
--cc=sachin.saxena@nxp.com \
--cc=sil-plv@napatech.com \
--cc=somnath.kotur@broadcom.com \
--cc=stephen@networkplumber.org \
--cc=syalavarthi@marvell.com \
--cc=thomas@monjalon.net \
--cc=vladimir.medvedkin@intel.com \
--cc=vsrivast@xilinx.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).