From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 23AA7A04F3; Wed, 8 Jan 2020 14:25:13 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CD1151D529; Wed, 8 Jan 2020 14:25:12 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id DC06D1D417 for ; Wed, 8 Jan 2020 14:25:11 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 82AF822006; Wed, 8 Jan 2020 08:25:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 08 Jan 2020 08:25:11 -0500 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=mesmtp; bh=blWbkswQxBL6NrCk2vQSP0UgS3F/Gl4HYkH0EgGM4Pw=; b=EEr5PmoQkYU/ iWzWZ0nQ3hvC5oYj45xCOPNw0HOUV12Au6hPgG9V0F7zPDBu1k2iKyYktGbh5tSe UNIVO8SE/dVWpy/NMGbEIluplvr+CcaPczUUREvmJwzfB0WrvjvQmtaOeLIitIK/ Z8EhZqtcnlSbCWba2Sv81clJ0LTmNkg= 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=fm1; bh=blWbkswQxBL6NrCk2vQSP0UgS3F/Gl4HYkH0EgGM4 Pw=; b=cuFYU1aeLX34qifMAKRAuHlJAw2VNLeWLMgwV+G0/4xBw+IxF1UTLf80l 28Wuko/k0dX+Dflf4owaTJ5kHH9RHdI8+htSvHQDsiX2OItJ4O/l5R5WUrY1TZE0 Z89Me1+07Ub2HlvcasjJ5Rq9ozolWe9vO7i5Ytl6xWK4z2qV3JXWr/nbbsg4zsg0 eiqt5IGxChNcp0Gz1VN0dlwD/BXdHvb5oknci9Dto6XJLnay36OEUOqo+CViX1J9 u73L6u97AhAeMPEERXQbeX53gogAdAMq3olkZXhEqMHUMzwzn/A87yJjCa00+CgV saymihfavFfULSPzWA9AErl1x8+7w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehkedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 0F0E08005C; Wed, 8 Jan 2020 08:25:09 -0500 (EST) From: Thomas Monjalon To: Laurent Hardy , David Marchand , Ferruh Yigit Cc: dev , Olivier Matz , Andrew Rybchenko Date: Wed, 08 Jan 2020 14:25:09 +0100 Message-ID: <3997232.ejJDZkT8p0@xps> In-Reply-To: <9ae94152-5be3-5356-94e6-a432fc3c02cb@intel.com> References: <20200107145637.8922-1-laurent.hardy@6wind.com> <1825898.usQuhbGJ8B@xps> <9ae94152-5be3-5356-94e6-a432fc3c02cb@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] librte_ethdev: extend dpdk api led control to query capability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 08/01/2020 14:20, Ferruh Yigit: > On 1/8/2020 1:06 PM, Thomas Monjalon wrote: > > 08/01/2020 13:59, Ferruh Yigit: > >> But for dev_ops, instead of having another capabilities indicator, which > >> requires PMDs to keep this synchronized, I think it is better if we can self > >> contain this information within dev_ops, like not implementing dev_ops would > >> mean it is not supported, this way it is easier to maintain and less error prone. > > > > It means the dev_ops is resetted at init if a device does not support the feature. > > It is against having const dev_ops. > > I didn't get your comment. > For example getting FW version, I am saying instead of keeping another piece of > information to say if it is supported by device/driver, better to grasp this > from if the driver implemented 'fw_version_get' dev_ops or not. I like this approach. Capabilities should be expressed by setting the function pointer or not (NULL). But a driver may support a feature for a subset of devices. If a device does not support a feature, the function pointer must be set to NULL. The only issue is having dev_ops as a const struct.