From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CBAFA43295; Mon, 6 Nov 2023 13:29:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 56B79402B6; Mon, 6 Nov 2023 13:29:41 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id C597A402AE for ; Mon, 6 Nov 2023 13:29:39 +0100 (CET) Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4SP9ZC2NKvzrTm7; Mon, 6 Nov 2023 20:26:27 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 6 Nov 2023 20:29:35 +0800 Subject: Re: [PATCH v5 2/5] net/sfc: use new API to parse kvargs To: Andrew Rybchenko , , CC: , , Vijay Kumar Srivastava References: <20230314124813.39521-1-fengchengwen@huawei.com> <20231106073125.55280-1-fengchengwen@huawei.com> <20231106073125.55280-3-fengchengwen@huawei.com> <4afbee3e-226c-4c1d-9a87-0a6198be5005@oktetlabs.ru> From: fengchengwen Message-ID: Date: Mon, 6 Nov 2023 20:29:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <4afbee3e-226c-4c1d-9a87-0a6198be5005@oktetlabs.ru> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Andrew, On 2023/11/6 18:28, Andrew Rybchenko wrote: > On 11/6/23 10:31, Chengwen Feng wrote: >> The sfc_kvargs_process() and sfc_efx_dev_class_get() function could >> handle both key=value and only-key, so they should use >> rte_kvargs_process_opt() instead of rte_kvargs_process() to parse. >> >> Signed-off-by: Chengwen Feng >> --- >>   drivers/common/sfc_efx/sfc_efx.c | 4 ++-- >>   drivers/net/sfc/sfc_kvargs.c     | 2 +- >>   2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/common/sfc_efx/sfc_efx.c b/drivers/common/sfc_efx/sfc_efx.c >> index 2dc5545760..3ebac909f1 100644 >> --- a/drivers/common/sfc_efx/sfc_efx.c >> +++ b/drivers/common/sfc_efx/sfc_efx.c >> @@ -52,8 +52,8 @@ sfc_efx_dev_class_get(struct rte_devargs *devargs) >>           return dev_class; >>         if (rte_kvargs_count(kvargs, RTE_DEVARGS_KEY_CLASS) != 0) { >> -        rte_kvargs_process(kvargs, RTE_DEVARGS_KEY_CLASS, >> -                   sfc_efx_kvarg_dev_class_handler, &dev_class); >> +        rte_kvargs_process_opt(kvargs, RTE_DEVARGS_KEY_CLASS, >> +                       sfc_efx_kvarg_dev_class_handler, &dev_class); > > LGTM from code point of view, but I'm not sure that I understand the > idea behind handling NULL value in sfc_efx_kvarg_dev_class_handler(). > > Cc: Vijay > >>       } >>         rte_kvargs_free(kvargs); >> diff --git a/drivers/net/sfc/sfc_kvargs.c b/drivers/net/sfc/sfc_kvargs.c >> index 783cb43ae6..24bb896179 100644 >> --- a/drivers/net/sfc/sfc_kvargs.c >> +++ b/drivers/net/sfc/sfc_kvargs.c >> @@ -70,7 +70,7 @@ sfc_kvargs_process(struct sfc_adapter *sa, const char *key_match, >>       if (sa->kvargs == NULL) >>           return 0; >>   -    return -rte_kvargs_process(sa->kvargs, key_match, handler, opaque_arg); >> +    return -rte_kvargs_process_opt(sa->kvargs, key_match, handler, opaque_arg); > > It looks wrong to me since many handlers do not handle NULL string gracefully. As I understand some handlers where fixed to avoid crash > and correct fix would be to keep  rte_kvargs_process() and remove > unnecessary checks for NULL string value. The scope is large, I suggest creates a new patchset later which remove unnecessary checks for NULL string value. > >>   } >>     int > > .