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 43141A0524; Tue, 13 Apr 2021 11:24:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C72C8160C17; Tue, 13 Apr 2021 11:24:22 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 11FC31609AD for ; Tue, 13 Apr 2021 11:24:20 +0200 (CEST) IronPort-SDR: DCe+Kk+x1zoLCSuJeXiVxq6nF5BSfbUh+RjcUmhUidZyQfn6LMFd66h0NB3MxIQsFhPOEn74to M552xguQtsuQ== X-IronPort-AV: E=McAfee;i="6200,9189,9952"; a="193936361" X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="193936361" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2021 02:24:19 -0700 IronPort-SDR: 38AonozQnCQvSGjidNBB7ueYvgG+hgKSVaBn9bnkhWw5PtA8VNG7IK8wBbIngJM8MCU1O2H+ZV liueWiDetnOw== X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="460518406" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.204.251]) ([10.213.204.251]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2021 02:24:18 -0700 To: Thomas Monjalon , Andrew Rybchenko Cc: "Min Hu (Connor)" , dev@dpdk.org References: <1618046334-39857-1-git-send-email-humin29@huawei.com> <1618284134-26152-1-git-send-email-humin29@huawei.com> <1950956.V83Gbnrlgs@thomas> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Tue, 13 Apr 2021 10:24:15 +0100 MIME-Version: 1.0 In-Reply-To: <1950956.V83Gbnrlgs@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] ethdev: add sanity checks in control APIs 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 Sender: "dev" On 4/13/2021 9:58 AM, Thomas Monjalon wrote: > 13/04/2021 10:44, Andrew Rybchenko: >> On 4/13/21 6:22 AM, Min Hu (Connor) wrote: >>> @@ -678,6 +684,9 @@ rte_eth_dev_owner_set(const uint16_t port_id, >>> { >>> int ret; >>> >>> + if (owner == NULL) >>> + return -EINVAL; >>> + >> >> Here and in many-many cases below I think the order of checks >> is important in cases when different error codes are returned. >> When there is no any very good reasons why arguments should >> be checked in different order, arguments should be checked in >> order specified in function prototype. In this cases (and many >> cases below), port_id should be checked first. >> >> In this particular case it means that the pointer check >> should be done in a static helper function. >> >> One more point is error logging in the case of failure. >> Right now I'd use RTE_ETHDEV_LOG(ERR, ...). May be later we'll >> find out that some of messages should be made INFO or DEBUG. >> Something like: >> RTE_ETHDEV_LOG(ERR, "Failed to set ethdev port %u owner to NULL\n", >> port_id); >> >> I'm not 100% sure in format, but my requirements are: >> - log messages should be unique >> - log messages should be human readable (i.e. I'd avoid >> usage of function name) >> - log messages should provide enough information to understand >> what went wrong and provide context (basically it correlates >> with uniqueness requirement) >> >> @Thomas, @Ferruh, what do you think? It would be good if we >> reach an argement before mass changes are done? > > I agree with all your comments Andrew. > +1 > >>> @@ -2491,6 +2515,12 @@ rte_eth_tx_done_cleanup(uint16_t port_id, uint16_t queue_id, uint32_t free_cnt) >>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); >>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_done_cleanup, -ENOTSUP); >>> >>> + if (queue_id >= dev->data->nb_tx_queues) { >>> + RTE_ETHDEV_LOG(ERR, "Queue id should be < %u.", >>> + dev->data->nb_tx_queues); >>> + return -EINVAL; >>> + } >>> + >> >> I'm not 100% sure that it is a control path. > > Indeed it can be used in the data path of some algorithms. > > >