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 BBBD0A0C3F; Thu, 15 Apr 2021 14:20:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A3DE1162231; Thu, 15 Apr 2021 14:20:19 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 257841621DC for ; Thu, 15 Apr 2021 14:20:18 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BFB3B5C0160; Thu, 15 Apr 2021 08:20:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 15 Apr 2021 08:20:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= YTJrSiPVejZAkxmbJDjLKKe4qZWv+Vj4crap986K+wg=; b=aXiJGL0uTnFn8Za4 gaiIj23iJik4aCtuduEkzKl2MYsum40hwKSLW0YxmagCIOxsp53pa+use/7MzBiz K9h5uROXdEY2QobAQj/Yhuu46UsFP+uoP+LvKP0DT4v4TlGnwy786r8jyNmxrapA R5Xix30Cg0BMPwmu/IJdgc0dSa1BExTZEq4h1kGXzIduF4dHi7pOX2KdUF4jkW7v H6niHvhxKo0sDRBOg1E/4Obt6Re1vj/C5/AYlGXZe6PMExu/Q8BAGWwcMt4+oYxL qzgg2cXaH8Se/83mKZ0l+uSi33IE4QNOdbXoZ64oPYmuv/qYv5y2pfdSIWg3LPd8 xkaKsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=YTJrSiPVejZAkxmbJDjLKKe4qZWv+Vj4crap986K+ wg=; b=ZHNe0h7g81nMoafogdMoyec+eiYfgtG8Qz7cXaabw7gqRlBTkb/IIs1P6 yP6oEOfRLX4q8LdiX8U7lEGHSqUj4I2VLt0Gr5kYMKQAzRSnQ8Qnx08Yjw9bugxg PtqaMNwqgd7cMCl6SNK8VYCcUKcmzrDvJYe6BaidWJCB5z+K5SnZWlcACyw3RQby TxKlc5U8r9k3nLIrpYlBcaaOzuZsUQC9xcOn4QTSK6OjNt/VKMXqusp9JuImOUX/ w1gtdJvJ0N3DBLXfrgp7HEadSEvh+KXk4iVnbRqy8Oxh0Mq4kA7ZcBHRMwQijE6H qt1hpr+9Zt+onoFWtFeBbCeIR+rdQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelfedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A86024005D; Thu, 15 Apr 2021 08:20:16 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: "Min Hu (Connor)" , dev@dpdk.org, ferruh.yigit@intel.com Date: Thu, 15 Apr 2021 14:20:15 +0200 Message-ID: <2363949.PJJJZldJTC@thomas> In-Reply-To: References: <1618046334-39857-1-git-send-email-humin29@huawei.com> <2252218.jVnlyW2HoW@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4] 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" 15/04/2021 14:03, Andrew Rybchenko: > On 4/15/21 2:57 PM, Thomas Monjalon wrote: > > 15/04/2021 10:15, Andrew Rybchenko: > >>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP); > >> In theory, the first argument is sufficient to make the ops > >> check, but I think it is the right solution to keep it as is > >> since current tendency is to check operation support when > >> driver callback is really required and we're going to use it. > >> However, if we do it just after port_id check, we'll have a > >> way to check for callback support without any side effects > >> if we provide invalid argument value. I.e. if -ENOTSUP is > >> returned, callback is not supported, if -EINVAL, callback is > >> supported (but argument is invalid and nothing done). > >> However, it looks a bit fragile and not always possible. > >> Thoughts on it are welcome. > > Sorry I don't understand it fully. > > You say we should check for ENOTSUP at the very beginning? > > I'm just trying to consider it and understand if it would be > right or wrong. I think it's better to check things when they are required. If the application does not give the right parameter, it won't be caught until a supporting device will be used. If the appplication gives the wrong parameter on purpose, because it won't be supported, then it's better not calling the function.